Project Setup: Modes, Keys, and Repair Callback

Configure a SendPromptly project with test/live mode, API keys, alert destinations, timeout settings, and a repair callback URL.

Project

A project is the top-level container for one monitored payment flow. It owns the API keys your app uses, the repair callback SendPromptly calls during reprocess, and the alerting and timeout settings used when incidents open.

Most teams use one project per production app or billing boundary. Keep different products, payment providers, or operational owners in separate projects so incidents, keys, and callbacks stay clear.

What belongs to a project

  • mode: test or live
  • One or more API keys
  • One repair callback URL
  • Alert destinations (email or Slack)
  • Incident timeout and optional per-project timeout override
  • Optional encrypted payload snapshots

Test and live mode

Use test while validating your integration and live when the flow is ready for production traffic. The app exposes mode at the project level, so you can keep test and live traffic clearly separated without inventing a full dev/stage/prod object model.

API keys

Create API keys per deployment context and label them clearly, for example:

  • Production key
  • Staging worker
  • CI validation

Store only the plaintext sk_... key in your backend secrets. The dashboard shows the full value once, then keeps only the hash. Rotate keys without downtime by generating a new key before revoking the old one.

Repair callback URL

Set a dedicated HTTPS endpoint that can safely rerun the original business effect. SendPromptly uses this URL only for reprocess requests from the incident console.

Your endpoint should:

  • verify the SendPromptly HMAC-SHA256 signature on the raw body
  • reject stale timestamps (older than 5 minutes) and replayed nonces
  • rerun the effect idempotently, keyed on replay_id
  • report the outcome to POST /api/v1/result

Alerts and timeout controls

Each project can define where incidents should be announced and how long SendPromptly should wait before treating a missing outcome as an incident.

  • Add email or Slack alert destinations for incident notifications.
  • Use timeout_minutes when a flow needs a shorter or longer missing-result window than the default 30 minutes. For time-sensitive revocation flows (subscription cancelled, refund issued), set a short timeout such as 5 minutes.
  • Per-event timeout overrides are also accepted in the receipt payload.

Payload snapshots

Payload snapshots are optional and encrypted at rest. By default, SendPromptly stores only metadata — event type, effect type, your internal reference, and status. Enable payload snapshots only when you need extra debugging detail. Snapshots are purged after 30 days.

Security baseline per project

  • API keys scoped to this project only
  • Separate signing secrets for repair callbacks and API authentication
  • All inbound requests require Idempotency-Key — duplicates are deduplicated, not double-processed
  • Audit log records all operator actions and state transitions
  1. Create the project in test mode.
  2. Set the repair callback URL.
  3. Generate an API key for the integration.
  4. Add at least one alert destination.
  5. Send a test acceptance signal and outcome signal.
  6. Force one failure to verify incident detection and email alert.
  7. Switch the project to live when the handler and repair path are proven.

A well-defined project boundary keeps incidents actionable and prevents the wrong team or callback endpoint from being involved in a paid-but-not-applied recovery.