Skip to content

Webhooks

Roster can send your software a notice when something changes, such as a recurring gift becoming active. This page is where you choose where those notices go and check whether they arrive.

Think of the destination as an inbox for your software. Its address is called a webhook endpoint. Your developer builds the receiver and supplies its public HTTPS address.

Select Add endpoint, enter the destination and choose the events it should receive. Each event describes a kind of change. Its message can contain many fields, which explains why the Glossary is much longer than the event list.

Register destinations separately in sandbox and production. Roster does not copy the test configuration into production.

When you create an endpoint, Roster shows its signing secret once. Your developer uses it to check that incoming messages really came from Roster. Store it securely. The API key has a different job: it gives your software permission to call Roster.

Use Show/Hide and Copy while the newly created secret is available. Do not include it in screenshots, support messages or shared documents.

Use this button to send a signed test message to the selected endpoint. It checks whether the address and receiver work, without creating a real donor or donation. Your developer will still need to test how your software handles the actual event types.

Select an endpoint and a date range. Delivered and Failed count delivery attempts during that period. Last success is the latest successful attempt in the same period.

The table shows the event, attempt time, response and event ID, with 50 attempts per page. Dates are in UTC. Delivery history is retained for 14 days, so this is not a permanent financial ledger.

A successful response tells you the receiver acknowledged the message. Ask your developer to check that your system applied the update too.

Roster can try again after a temporary failure. There is a limit to automatic retries. If the address is wrong or the receiver has a bug, your developer needs to fix it.

The same event may arrive more than once. Your software needs to recognize it so a repeated notice does not become another donation in your records. If a notice is missed, your developer can retrieve the update from the event or financial feed. The troubleshooting link explains what to check when problems persist.

Removing an endpoint stops deliveries to that destination. Confirm that the destination is no longer needed before removing it.