Configure webhooks for claim responses
You can set up webhooks that automatically send events for processed 277s and 835s to your endpoint. The event payload contains the information you need to retrieve these responses from Stedi. You can either create a single webhook that forwards events from all transactions, or create a separate webhook for each transaction type.
Configuring a webhook involves:
- Creating a credential set for authentication to the endpoint.
- Creating a webhook that specifies the URL where Stedi should deliver events.
- Adding one or more event bindings that trigger the webhook.
Credential set
A credential set defines how to authenticate with a specific API. You can use a single credential set across multiple webhooks. Stedi supports the following types of configurations.
Type | Description |
---|---|
API Keys | The API keys as headers in the request. The most common version is ‘bearer tokens’. |
Basic Auth | HTTP Basic Auth, where you provide a username and password. |
None | For endpoints that don’t require any authentication. |
Unauthenticated endpoints
When using the ‘None’ credential set type in webhooks, it’s functionally the same as using ‘API Keys’. However, we set a dummy value for Header name
and Value
(x-stedi-noauth
and dummy
). Since the receiving API isn’t authenticating the call, it will ignore these values and accept the request.
Create credential set
You can define a credential set as part of configuring a new webhook. You can also create a new credential set independently and then attach it to one or more webhooks.
To create a credential set:
- Go to the Webhooks page.
- Click Manage credentials, and then click Create credential set.
- Enter a name.
- Choose the appropriate Authentication type.
- Enter the details.
- Click Create credential set.
Webhook
A webhook defines which URL endpoint Stedi should call when the webhook is invoked, and which HTTP method to use (POST
, PUT
, GET
, PATCH
, DELETE
).
You can only attach one credential set to each webhook. However, you might have multiple webhooks for a single system integration, each with a different endpoint.
Create webhook
To create a new webhook:
- Go to the Webhooks page.
- Click Create webhook.
- Enter a name.
- Choose a Method and enter an Endpoint URL. This is where Stedi delivers the events when the webhook is invoked.
- Select a Credential set to use for authentication or create a new one for this endpoint.
- (Optional) Set the Concurrency. You can set the maximum number of deliveries that Stedi will attempt to deliver to the endpoint at one time. This can help you avoid overloading the target service.
Event bindings
Event bindings allow you to specify which events trigger the webhook. You can create multiple event bindings for a single webhook. For example, you may want to create an event binding for each type of transaction you want to send to your API.
Create event binding
To create a new event binding:
- Go to the Webhooks page.
- Click the webhook.
- Click the Event bindings tab.
- Click New event binding.
- Choose Transaction processed as the Event type.
- (Optional) Set one or more filters.
- Click Create binding.
Choosing event types
At a minimum, you should create an event binding for transaction processed events. You may also want to set up event bindings for file delivered and file failed events, depending on your use case.
(Recommended) Transaction processed events
Stedi emits a transaction processed event after it successfully receives and translates a payer or peer clearinghouse response into JSON. The event payload contains the information you need to retrieve processed responses from Stedi:
x12.transactionSetIdentifier
specifies the transaction type (277 or 835).transactionId
allows you to retrieve the transaction from Stedi using either the 277CA Report or 835 ERA Report endpoint.
File delivered events
Stedi emits a file delivered event when it successfully generates and delivers a claim. You may want to send these events to your system for monitoring and alerting.
Note that this event is emitted when Stedi delivers your claim to our connection with the payer. It doesn’t indicate whether the payer received the claim or whether they have accepted or rejected it.
File failed events
Stedi emits a file failed event when it either fails to process a response from a payer or cannot deliver a submitted claim.
We monitor for file failed events internally because they are usually the result of connection problems or other issues that our engineering team must resolve with the payer. However, you may want to also monitor these events so you can alert our customer support team if needed.
Event filters
You may want to further filter the events Stedi sends to your endpoint:
- Transaction: This is useful if you want to send events for 277 Claim Acknowledgments to one endpoint and events for 835 ERAs (claim payments) to another. For example, if you set this to
277: Health Care Information Status Notification
, Stedi only sends events for processed 277s to your endpoint. - Partnership: This is useful if you want to send test claims to one endpoint and production claims to another. For example, if you set this to
local-clearinghouse-test
, Stedi only sends events for test claims to your endpoint.
HTTP response codes
Stedi considers a 2xx response a success, and marks any other response as a failure.
Stedi retries events associated with status codes other than 2xx
for up to 4 times with a 90 second wait period inbetween retries.
If the maximum number of retries has been exhausted, Stedi adds the event to the error queue for the webhook.
You can set the Concurrency when configuring the webhook to prevent throttling. This setting determines the maximum number of deliveries that Stedi will attempt to deliver to the endpoint at one time.
Response time
The target endpoint must respond within 5 seconds, or the event will be counted as a failed delivery.
Retries
When a delivery fails, Stedi will retry up to 4 times every 90 seconds. After the fifth retry, Stedi moves the event to the error queue.
Duplicate deliveries
If your webook doesn’t respond within 5 seconds, Stedi marks that as a failure and then automatically retries. This can result in duplicate deliveries, so we strongly recommend implementing ways to manage duplicates delivered through webhooks.
Error queue
Each webhook includes an error queue. Each item in the queue consists of the original event that was attempted to be delivered. This ensures if the target service has some downtime, or anything else goes wrong, the missed events can be retried later. The error queue retains items for 14 days.
The order of the error queue is not guaranteed. The downstream service must be designed to be idempotent to handle at-least-once delivery of events, and must accept events out of order.
Logs
To view logs, click the webhook to go to its detail page, and then navigate to the Logs tab.
Deauthorized connections
If a webhook sends a message to an endpoint that returns a 401 (Unauthorized) response, the destination will be ‘deauthorized’. In this state, the webhook won’t be able to deliver messages.
If there is an issue with your authentication information (such as the password, API key, or OAuth settings), edit the webhook to fix it.
If the authentication information is correct, and there was a different reason for the endpoint returning a 401, you can try again by adding a temporary header. For example, x-stedi-reauthorize
with today’s date as a value. When you save, the webhook will attempt to deliver again. This header can be removed later. Editing the value of a header will also restart deliveries.
You will likely have a queue of messages to deliver, so Stedi will automatically start retrying them after you make this change. If the endpoint is still returning an invalid response, the webhook will return to Deauthorized
.
Was this page helpful?