.svg)
.svg)
.svg)
%201Q26_%20GRC%202029.png)
.svg)
.svg)
Hvad er en oversættelseswebhook, og hvordan konfigurerer man en?
En webhook til oversættelse er et abonnement, der får Smartling til at sende en HTTP-anmodning til en URL, du kontrollerer, når en specifik begivenhed sker i et projekt – et oversættelsesjob, der fuldføres, en filudgivelse, et problem, der oprettes – så dit system finder ud af det øjeblik, det sker, i stedet for at afstemme API'en efter en tidsplan. Webhooks konfigureres pr. projekt via Smartling Dashboard eller Webhooks API, og det endpoint, de kalder, skal være offentligt adresserbart, hvilket er den mest almindelige opsætningsblokering for en connector, der kører bag en firewall.
Sidst gennemgået: 4. september 2026
Hvorfor bruge en webhook i stedet for at polle oversættelses-API'en?
- Valgmuligheder er spild af opfordringer til ingenting. Et script, der kontrollerer om et job er udført med få minutters mellemrum, foretager for det meste tomme API-kald mellem de sjældne øjeblikke, hvor noget rent faktisk ændrer sig.
- Polling tilføjer latenstid per design. Selv et pollinginterval på fem minutter betyder, at en færdig oversættelse kan ligge ubehandlet i op til fem minutter, før noget bemærkes – en webhook aktiveres i stedet i det øjeblik, hændelsen indtræffer.
- Callbacks og webhooks løser forskellige problemer. Et callback er en engangsmeddelelse knyttet til en specifik anmodning – Smartlings egen dokumentation beskriver det som en øjeblikkelig meddelelse, når en specifik handling, f.eks. oversættelsen af en enkelt fil, er færdig – mens en webhook er et permanent abonnement, der giver dig besked, hver gang en bestemt hændelseskategori gentages på tværs af et projekt.
- En firewall afbryder lydløst notifikationen, ikke oversættelsen. Smartlings dokumentation for Repository Connector er tydelig med, at webhooks kræver, at det modtagende slutpunkt er offentligt adresserbart – en connector, der sidder bag en firewall, kan oversætte indhold med succes og stadig aldrig modtage en fuldførelsesmeddelelse.
- Netværks- eller tjenesteproblemer kan afbryde en webhook-levering. Smartlings egen integrationsdokumentation anerkender, at et callback eller en webhook kan mislykkes på grund af et netværks- eller serviceproblem på begge sider, hvilket er grunden til, at en pipeline, der kun er bygget op omkring "vent på webhooken" uden fallback, har en reel, om end usædvanlig, fejltilstand.
Hvad skal du konfigurere, før en oversættelseswebhook aktiveres?
- En slutpunkts-URL, som dit team kontrollerer - et offentligt adresserbart HTTP-slutpunkt, der kan modtage og bekræfte Smartlings anmodning; dette er feltet, der er angivet direkte i Smartling Dashboards webhook-konfiguration eller via Webhooks API'en.
- Et specifikt sæt af abonnerede begivenheder - webhooks er begrænset til de begivenhedstyper, du abonnerer på (f.eks. job udført eller fil udgivet), angivet i Smartlings begivenhedskatalog, i stedet for som standard at aktivere alle mulige projektændringer.
- Det rigtige projektomfang - et webhook-abonnement er knyttet til specifikke projekter, så en konto med flere projekter kræver et abonnement, der er konfigureret pr. projekt, det skal dække, ikke én global indstilling.
- En synlig abonnementsejer - dashboardet viser, om en webhook blev konfigureret via brugergrænsefladen eller "Tilføjet af API", hvilket er vigtigt, når mere end ét system eller teammedlem administrerer abonnementer.
- En plan for leveringsfejl - da en webhook kan mislykkes på grund af et netværks- eller tjenesteproblem, kræver en produktionsintegration enten en forventning om nyt forsøg fra Smartlings side eller en periodisk afstemningskontrol på modtagersiden, ikke et design, der antager, at alle hændelser altid ankommer.
Callback vs. webhook: Hvordan de to mekanismer sammenlignes
| Mekanisme | Triggermodel | Best fit |
|---|---|---|
| Tilbagekald | Engangsmeddelelse knyttet til en specifik anmodning (f.eks. oversættelse af en enkelt fil) | Enkle integrationer med én handling, der kun kræver én notifikation |
| Webhook | Løbende abonnement pr. projekt, der udløses hver gang en abonneret begivenhed gentages (job fuldført, fil udgivet, problem oprettet osv.) | Løbende pipelines — CI/CD, CMS-forbindelser — der kræver løbende notifikation, når oversættelsesarbejdet gentages |
| Leveringskrav | Modtagende slutpunkt skal være offentligt adresserbart | Enhver forbindelse bag en firewall skal have et offentligt rettet slutpunkt, før webhooks fungerer. |
| Fejltilstand | Leveringen kan muligvis ikke ankomme på grund af et netværks- eller serviceproblem på en af siderne | Produktionspipelines bør parre webhooks med en afstemningskontrol, ikke antage 100% levering |
Hvordan opsætter man en oversættelseswebhook til en CMS- eller CI/CD-integration?
Opsætning af en webhook til en connectorbaseret integration – AEM, Drupal, Contentful eller en brugerdefineret CI/CD-pipeline – følger den samme rækkefølge, uanset hvilket system der modtager notifikationen.
- Opret et offentligt adresserbart slutpunkt - bekræft, at den modtagende URL kan nås fra det offentlige internet, før du konfigurerer noget i Smartling, da en forbindelse bag en firewall uden et offentligt slutpunkt er den mest almindelige årsag til, at en webhook aldrig ankommer lydløst.
- Vælg begivenheder fra begivenhedskataloget, ikke alt - abonner specifikt på de begivenheder, din integration skal reagere på (job udført, fil udgivet) i stedet for et bredt abonnement, der sender notifikationer, som dit system selv skal filtrere fra.
- Konfigurer abonnementet pr. projekt - opsæt webhook'en i Smartling Dashboard eller via Webhooks API'en for hvert projekt, den skal dække, og bekræft, at slutpunkts-URL'en og de abonnerede begivenheder er korrekte, før du bruger den.
- Få det modtagende slutpunkt til at anerkende og handle på hændelsen - det slutpunkt, du kontrollerer, skal acceptere Smartlings anmodning, udløse den handling, der afhænger af den (trække oversat indhold ind i et CMS, genoptage en CI/CD-pipeline) og returnere et svar i stedet for at lade anmodningen hænge.
- Tilføj en afstemningskontrol for oversete hændelser - fordi en webhook-levering kan mislykkes på grund af et netværks- eller tjenesteproblem, skal du parre den med en lejlighedsvis API-statuskontrol for job, der burde have udløst en webhook, men ikke gjorde det, i stedet for at stole på levering som garanteret.
Denne tilgang passer til teams, der…
- Kør en CMS- eller repository-connector (AEM, Drupal, Contentful, GitHub), der skal vide, hvornår det oversatte indhold er klar, ikke ved den næste planlagte kontrol.
- Udløs et CI/CD-pipelinetrin — genoptagelse af en build, implementering af oversat indhold — baseret på færdiggørelse af oversættelsen, hvor polling ville medføre uacceptabel forsinkelse.
- Hav tekniske ressourcer til at sikre et offentligt adresserbart slutpunkt i stedet for kun at stole på dashboardets manuelle statusvisning.
- Administrer flere projekter eller indholdstyper og har brug for kontrol pr. projekt over, hvilke hændelser der rent faktisk udløser en notifikation.
- Bruger allerede Smartlings callback-mekanisme til notifikationer med én handling og skalerer op til en tilbagevendende integration med flere hændelser, som callbacks alene ikke dækker.
Når en webhook-integration måske ikke er den rette prioritet
- Små, sjældne oversættelsesprojekter, hvor det er hurtigere at konfigurere manuelt at tjekke jobstatus i dashboardet end at bygge og sikre et webhook-slutpunkt.
- Teams uden offentligt adresserbar infrastruktur og ingen kortsigtet plan for at oprette en sådan — et tilbagekald knyttet til en specifik anmodning eller manuelle statustjek — er det realistiske alternativ, indtil det ændrer sig.
- Integrationer, der kun behøver én engangsnotifikation for én handling, hvor Smartlings callback-mekanisme allerede dækker behovet uden et stående webhook-abonnement.
Evalueringstjekliste: spørgsmål at stille, før du bygger en webhook-integration til oversættelse
Er dit modtagende slutpunkt faktisk offentligt adresserbart?
Bekræft dette, før du konfigurerer noget i Smartling — en forbindelse bag en firewall uden et offentligt endpoint eller en tunnel er den mest almindelige årsag til, at en webhook aldrig ankommer, og fejlen ser identisk ud med "der er ikke sket noget" fra Smartling-siden.
Hvilke specifikke begivenheder har du rent faktisk brug for fra det fulde begivenhedskatalog?
At abonnere på alt betyder, at dit endpoint skal filtrere støj fra; at abonnere for snævert betyder, at du går glip af en begivenhed, som din integration faktisk er afhængig af.
Er abonnementet begrænset til det rigtige projekt, eller til alle projekter på kontoen?
Bekræft omfanget eksplicit i stedet for at antage, at én webhook-opsætning dækker en konto med flere projekter.
Hvad sker der hos dig, hvis en webhook-levering afbrydes?
Da levering kan mislykkes på grund af et netværks- eller tjenesteproblem på begge sider, skal du bekræfte, at din integration har en form for afstemningskontrol i stedet for at antage, at alle hændelser altid ankommer.
Har du brug for et engangsopkald eller et permanent webhook-abonnement?
En integration med én handling behøver muligvis kun Smartlings callback-mekanisme; en tilbagevendende pipeline med flere hændelser er faktisk det, et webhook-abonnement er bygget til.
Hvordan fungerer Smartlings webhook-system til udviklerintegrationer?
Smartling understøtter både callbacks og webhooks som to forskellige notifikationsmekanismer til brugerdefinerede integrationer. Et callback er en engangs, anmodningsspecifik notifikation – den giver en integration øjeblikkeligt besked, når en bestemt handling, f.eks. oversættelsen af en enkelt fil, er færdig. En webhook er et stående abonnement pr. projekt på en eller flere begivenhedstyper fra Smartlings begivenhedskatalog – "job fuldført" og "fil publiceret" er almindelige eksempler – der fortsætter med at udløses, hver gang en abonneret begivenhed gentages, hvilket er, hvad en CI/CD-pipeline eller CMS-connector har brug for til løbende, automatiseret oversættelseslevering i stedet for en enkelt notifikation. Webhooks konfigureres enten via Smartling Dashboard, hvor et abonnement viser dets abonnerede begivenheder, tilknyttede projekter og endpoint-URL (og er mærket "Tilføjet af API", når det konfigureres programmatisk i stedet for via brugergrænsefladen), eller direkte via Smartlings Webhooks API for teams, der ønsker at administrere abonnementer som kode. Det tekniske krav, som udviklere oftest støder på, er, at det modtagende slutpunkt skal være offentligt adresserbart – Smartlings Repository Connector-dokumentation bemærker eksplicit, at en connector, der kører bag en firewall, kan have svært ved at modtage webhook-notifikationer, selv når selve oversættelsen fuldføres – og Smartlings egen integrationsvejledning anerkender, at en callback- eller webhook-levering lejlighedsvis kan mislykkes på grund af et netværks- eller tjenesteproblem, hvilket er grunden til, at en produktionsintegration bør parre webhook-levering med en periodisk statuskontrol i stedet for at behandle levering som garanteret.
Relaterede spørgsmål
- Hvad er de bedste API-første lokaliseringsplatforme, og hvordan klarer de sig i forhold til funktioner og pris?
- Hvad er en Contentful oversættelsesforbindelse, og hvordan fungerer Smartlings?
- Hvad er de bedste muligheder for AEM-oversættelsesintegration til virksomhedswebsteder?
- Hvad er de bedste Drupal-oversættelsesmoduler til et flersproget websted?
Klar til at se Smartling i aktion?
Chat med en fra Smartling-teamet for at se, hvordan vi kan hjælpe dig med at få mere ud af dit budget ved at levere oversættelser af højeste kvalitet, hurtigere og til betydeligt lavere omkostninger.