Developer API for Partner Webhooks

A developer API for partner webhooks that gives installable apps one endpoint model for lifecycle events, installed-merchant events, secret rotation, and delivery ownership.

Teams searching partner-webhook APIs usually already have OAuth install working. The next problem is owning app lifecycle events, installed-merchant resource events, signing secrets, and retry history without mixing them into merchant-level webhook endpoints.

Flint exposes a dedicated partner-app webhook surface rather than forcing installable apps onto the same endpoint model used for a merchant's own resource webhooks.

The public model covers create, read, patch, delete, and rotate-secret on the partner app itself, which makes lifecycle ownership explicit.

Apps can choose between lifecycle events and installed-merchant event forwarding instead of pretending every third-party integration needs the same event shape.

Open the Technical Surface

Quickstart

Start with the first request.

API Reference

Open the REST surface.

Orders First

See the core model.

Benchmark

Compare developer workflows.

Use This Platform Shape When

Platform 1

Your installable app needs its own event endpoint instead of reusing a merchant's regular order or payment webhook.

Platform 2

You need to choose between app lifecycle events and installed-merchant event forwarding on the same partner-app model.

Platform 3

Your team needs secret rotation and a clean ownership boundary after OAuth install succeeds.

Scenario 1

App lifecycle monitoring

Track installs, revocations, and permission changes on an endpoint the partner app owns instead of inspecting install state manually.

Scenario 2

Installed-merchant forwarding

Receive resource events for installed merchants on one app endpoint when your product needs to react after the install handshake.

Scenario 3

Single endpoint per app

Keep the webhook contract tied to the partner app itself instead of scattering one-off merchant endpoints across your ecosystem surface.

Scenario 4

Operational secret rotation

Rotate the partner webhook secret explicitly when environments or signing hygiene change without rebuilding the app registration flow.

Choose Something Narrower When

Use the broader partner-app page when the main design question is app registration, install records, and token exchange.

Use webhook infrastructure when the current work is regular merchant resource events instead of partner-app-specific delivery.

Use direct polling when the integration is low-volume and no durable event stream needs to drive downstream behavior.

Implementation References

Reference the platform-level surfaces

Partner Apps API

Configure the partner app webhook endpoint, source type, and secret rotation on the installable app resource.

Partner App Installs Guide

See the lifecycle-versus-installed-merchant webhook patterns and the one-endpoint-per-app model.

Webhooks Guide

Reuse Flint's signature verification and delivery-handling patterns on partner-app webhook endpoints too.

Explore app installs, hosted auth, and webhook operations

These pages connect partner-app delivery to the OAuth install flow and Flint's wider event model.

Partner Apps API

Use this when the current design problem is the full installable app surface, not just the webhook ownership model.

OAuth for Commerce Integrations

Go here when the missing step is merchant approval and code exchange rather than post-install event delivery.

Webhook Infrastructure for Developers

Useful when app-owned webhooks also need to fit a broader order, invoice, and refund event strategy.

Next Step

Wire the platform boundary first

Define auth, merchant scope, and install flow first, then let the narrower payment and checkout pages sit underneath it.