Registra només els esdeveniments que necessites
Crea un endpoint ambPOST /v3/webhooks. Subscriu-te només als esdeveniments documentats que impulsen la teva integració. Aquest exemple utilitza transfer.state_changed.
Create webhook endpoint
data.id de la resposta com a WEBHOOK_ID. Sol·licita una URL de portal a GET /v3/webhooks/portal amb una clau d’API que tingui webhooks:write, recupera el secret de signatura d’aquest endpoint i emmagatzema’l per separat de la teva clau d’API en un gestor de secrets. La URL del portal dona accés per si sola i caduca al cap d’una hora, així que sol·licita’n una de nova cada vegada i no la desis ni la comparteixis.
El portal agrupa els esdeveniments v3 per recurs: Customers, Capabilities, Accounts, Recipients, Transfers i API. Cada esdeveniment mostra el seu esquema de càrrega útil i un exemple. Els esdeveniments heretats es marquen com a obsolets i es llisten en un grup Legacy separat. Si el teu endpoint ja està subscrit a un esdeveniment heretat, el continua rebent. Tria noms d’esdeveniments v3 per a les subscripcions noves.
Canvia els esdeveniments d’un endpoint
Llegeix un endpoint ambGET /v3/webhooks/{webhookId}. La resposta té la mateixa forma de events que GET /v3/webhooks. Mai no inclou el secret de signatura. Les lectures requereixen webhooks:read i retornen 404 not_found per a un ID d’endpoint desconegut.
Actualitza l’endpoint amb PATCH /v3/webhooks/{webhookId}. Envia una capçalera Idempotency-Key. Les actualitzacions requereixen webhooks:write.
- Envia només
eventsper conservar l’URL actual. - Envia només
urlper conservar la selecció d’esdeveniments actual. eventssubstitueix tota la selecció. Llegeix primer l’endpoint i inclou-hi tots els esdeveniments que encara necessitis.- Les subscripcions noves han d’utilitzar noms d’esdeveniments v3.
- Pots conservar un nom d’esdeveniment heretat si l’endpoint ja hi està subscrit. Afegir un nom heretat nou retorna
400 validation_error.
Request body
Verifica abans d’analitzar
Swipelux lliura les noves integracions de webhooks a través de Svix. Verifica el cos brut de la sol·licitud amb el secret de signatura del teu endpoint i aquestes capçaleres:svix-idsvix-timestampsvix-signature
Verify signature
Persisteix, reconeix, i després processa
Posa una restricció d’unicitat sobre l’id de l’envolupant. Persisteix l’envolupant verificat, retorna 2xx ràpidament i després processa’l de manera asíncrona.
Si l’ID de l’esdeveniment ja existeix, reconeix el lliurament sense repetir els efectes secundaris ja completats. Reprèn el treball local pendent o fallit mitjançant la teva pròpia cua de reintents. No utilitzis el camp attempt de l’envolupant com a clau de deduplicació o comptador de reintents de transport.
Torna a obtenir l’estat actual
L’ordre dels webhooks no és un historial autoritatiu del recurs. Utilitzaresource.type i resource.id per localitzar l’objecte, i després obté el seu estat actual abans d’actualitzar el teu sistema.
Per a un esdeveniment de transferència, crida GET /v3/transfers/{transferId}:
Refetch transfer
Recupera lliuraments
UtilitzaGET /v3/webhooks/portal per obrir registres de lliurament. Amb webhooks:write, també pots reintentar lliuraments fallits o iniciar una repetició manual. Una clau amb només webhooks:read obre un portal que mostra els lliuraments, però no pot reintentar-los, repetir-los ni revelar els secrets de signatura.
Cada repetició ha de passar per la mateixa verificació de signatura i safata d’entrada durable. Per recuperar-te després d’una inactivitat, repeteix la finestra afectada i torna a obtenir cada recurs referenciat. Els IDs d’esdeveniments completats romanen com a no-ops; els registres incomplets es reprenen de manera asíncrona.
A continuació, verifica els lliuraments duplicats i fora d’ordre al sandbox, i després completa la llista de comprovació Anar en producció.