Skip to content
ShuttleShuttle Docs
Status
View as MarkdownPlain text for AI toolsOpen in ClaudeAsk questions about this pageOpen in ChatGPTAsk questions about this pageOpen in GitHub CopilotAsk questions about this page

Via the API

API access comes with a paid plan. An Admin finds the account’s API keys in the Merchant Portal under Configure > Account, under API Keys. See Authentication for merchants.

Section titled “Payment link API”

Shuttle provides four operations for creating and managing payment links:

Section titled “Handling payment link notifications with webhooks”

Shuttle sends your applications notifications by webhook. Depending on your relationship with Shuttle, you can receive payment link webhooks in two ways:

  • webhook_target on the instance (a specific Shuttle account): receives every event for that account. In the Merchant Portal, an Admin sets it under Configure > Account, in Webhook URL.
  • webhook_target on the application: software platforms receive every event for all the accounts linked to their application.

An account’s own webhook_target replaces the application’s for that account. See Webhooks.

When you use a workflow automation tool, its webhooks are set on the account, so you receive every webhook for that account (including ones that aren’t about payment links). Filter for the ones you want using the action and state fields.

Webhook security

Section titled “Webhook security”

Webhooks are sent from a secure server and contain the following security measures:

  • Webhooks do not contain any sensitive information, just object references. You must fetch them via the API using your API credentials.
  • Webhooks must be to a HTTPS target on port 443.
  • All webhooks will come from one of the following IP addresses:
    • 52.51.86.26
    • 54.229.12.118
    • 54.76.31.104
    • 34.252.246.134

Webhook retry policy

Section titled “Webhook retry policy”

A webhook that returns any 2xx HTTP status is treated as successful. Any other status is treated as a failure.

By default webhooks are not retried unless you activate a retry policy. You can activate a webhook retry policy using the following syntax. Each retry will typically happen after 1 minute.

  • |: sets the number of attempts, eg https://targetA/url|3 (attempt 3 times)
  • >: failover to a second URL, eg https://targetA/url>https://targetB/url (attempt targetA, then attempt targetB)
  • ,: send a webhook to multiple destinations eg https://targetA/url,https://targetB/url (sent to targetA AND targetB)

Examples:

  • https://targetA/url - send the webhook to targetA
  • https://targetA/url|2 - send the webhook to targetA, and if a 2xx status isn’t returned, try again 1 minute later
  • https://targetA/url|120 - send the webhook to targetA every minute until successful for 2 hours
  • https://targetA/url>https://targetB/url - send the webhook to targetA, if fail send to targetB after 1 minute
  • https://targetA/url>https://targetB/url>https://targetC/url - send the webhook to targetA, then targetB, then targetC (etc)
  • https://targetA/url|60>https://targetB/url|5 - send the webhook to targetA every minute for an hour then failover to targetB for 5 minutes
  • https://targetA/url,https://targetB/url - send the webhook to targetA and targetB
  • https://targetA/url|60,https://targetB/url|60 - send the webhook to targetA for up to an hour and targetB for up to an hour

Note: Retries are DISABLED in the sandbox environment.

Was this page helpful?