{"templateId":"openapi_docs","versions":[{"version":"v1","label":"v1","link":"/api-reference/v1/webhooks","default":false,"active":false,"folderId":"1b9c9f54"},{"version":"v2","label":"v2","link":"/api-reference/webhooks","default":true,"active":true,"folderId":"1b9c9f54"}],"sharedDataIds":{"openAPIDocsStore":"oas-api-reference/@v2/index.yaml","sidebar":"sidebar-sidebar.yaml__api-reference"},"props":{"definitionId":"api-reference/@v2/index.yaml","dynamicMarkdocComponents":[],"baseSlug":"/api-reference","seo":{"title":"Webhooks","siteUrl":"https://developer.flute.com","description":"Webhooks are notifications that are automatically sent when specific predefined events occur.\n\nWebhooks are commonly used, for instance, when payment processors need to notify a client that a charge succeeded or failed, when a subscription renews, or an incoming SMS message is available.\n\nThey replace polling.\nThis polling might have been:\n* Software polling for a status change either through a loop, or timed queries.\n* Manually by a user explicitly polling expecting a response or pending status to be returned.\n\nA merchant can only affect their own webhooks.\nThey cannot view or modify other merchant's webhooks.\nLikewise, a partner can only affect merchants associated to them.\nThey cannot affect merchants of other partners.\n\n**Required API Permissions**<br>\nRequired API Permission: Webhooks\n\n**Webhook Workflows**<br>\nTo create and manage Flute webhooks, use the following procedures and workflows.\n\n**Creating Webhooks**<br>\n1\\) Optionally, review all the valid event types.\nWebhooks can accept one or more event types.\nEach event type is evaluated independently.\nSelected events are not required to be related and may relate to different transaction types or workflows.\nFor organizational reasons, multiple webhooks can be created.\nEach webhook can then have it's own set of event types.\n\nTo list all available events, see `GET /v2/webhooks/event-types`\n\n2\\) Create the webhook<br>\nTo create the webhook, see `POST /v2/webhooks/endpoints`\n\n3\\) Test the webhook<br>\nVerify the endpoint is reachable (sends a test ping).<br>\nTo test the webhook, see `POST /v2/webhooks/endpoints/{webhookId}/ping`\n\n**Managing Webhooks**<br>\nThe following set of endpoints manage webhooks.\n\n* This endpoint provides a list of all available webhook for the merchant.<br>\nTo list all the available webhooks, see `GET /v2/webhooks/endpoints`\n\n* This endpoint retrieves webhook details specified by its webhookId.<br>\nTo retrieve a specific webhook, see `GET /v2/webhooks/endpoints/{webhookId}`\n\n* This endpoint provides an ability to update or change a webhook.\nFor example, the set of event types may be changed without having to create a new webhook.<br>\nTo modify or update a specific webhook, see `PUT /v2/webhooks/endpoints/{webhookId}`\n\n* This endpoint deletes the specific webhook.\nThis action can neither be undone nor can the webhook be retrieved.\nThis does not erase entries in the log file.<br>\nTo delete a specific webhook, see `DELETE /v2/webhooks/endpoints/{webhookId}`\n\n**Monitoring Webhooks**<br>\nThe following set of endpoints monitor webhooks.\nThese may be used to verify success of an attempt or assist in determining the cause of a problem.\n\n* This endpoint lists success level of delivery attempts.<br>\nTo view webhooks delivery attempts log file, see `GET /v2/webhooks/delivery-logs`\n\n* This endpoint lists success level of delivery attempts for a specified webhook.<br> \nTo view a specified webhook delivery attempts log file, see `GET /v2/webhooks/delivery-logs/{webhookId}`\nGet full request/response detail for a single attempt\n\n* This endpoint exports the delivery logs file.\nIt may be specified as either a CSV or JSON format.<br>\nTo export webhooks delivery attempts log file, see `GET /v2/webhooks/delivery-logs/export`\n\n* This endpoint retries a failed delivery.<br>\nTo retry a failed delivery, see `POST /v2/webhooks/delivery-logs/{id}/retry`\n\n**Client Handling of Messages**<br>\nThe webhook sends a message to the URL specified by the client.\nThis is `endpointUrl` of `POST {{baseURL}}/v2/webhooks/endpoints`.\nThe message is considered successfully sent after a send confirmation is received.\nIf that send confirmation was not successfully confirmed, the message will be sent, or retried, a number of times before failing.\n\nAfter being successfully sent to the receiving endpoint or URL, \nit is the client's responsibility to handle it after that.\nAs a best practice, we recommend that the message is first verified to be from Flute.\nFor example, use HMAC verification.\nThis step greatly increases security and reduces system vulnerabilities such as spoofing, tampering, or data injection.\nThe IP address could be blocked to prevent future intrusions.\n\nOnce the sender is verified, the client can process the message as they need.\nFor example, code or an application on the receiving server may create an email or SMS message to send to the client.\n","lang":"en-US","llmstxt":{"hide":true,"excludeFiles":[]}},"itemId":"webhooks","disableAutoScroll":true,"metadata":{"subType":"openapi-operation"},"compilationErrors":[],"markdown":{"partials":{},"variables":{"rbac":{"teams":["anonymous"]},"user":{},"remoteAddr":{"hostname":"developer.flute.com","port":4000,"ipAddress":"216.73.216.41"},"lang":"default_locale","env":{"PUBLIC_REDOCLY_BRANCH_NAME":"main"}}},"pagePropGetterError":{"message":"","name":""}},"slug":"/api-reference/webhooks","userData":{"isAuthenticated":false,"teams":["anonymous"]},"isPublic":true}