# 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 fo

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](/merchants/reference/api-keys/).

## Payment link API

Shuttle provides four operations for creating and managing payment links:

* [`POST /payment_links`](/merchants/reference/operations/createpaymentlink/) - Create a new payment link
* [`GET /payment_links/{id}`](/merchants/reference/operations/getpaymentlink/) - Get a specific payment link
* [`PUT /payment_links/{id}`](/merchants/reference/operations/updatepaymentlink/) - Update an existing payment link
* [`DELETE /payment_links/{id}`](/merchants/reference/operations/archivepaymentlink/) - Delete (archive) a specific payment link

## 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](/merchants/reference/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

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

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.