The Resolve API is organized around REST principles. It uses predictable resource-oriented URLs, standard HTTP verbs and response codes, and accepts and returns JSON-encoded request and response bodies.

Resolve offers both server-side and client-side integrations. This documentation refers to the server-side API. Refer to our e-commerce plugin guides for details on client-side checkout solutions.

There is a sandbox API available for testing, which leverages the same data store as your sandbox dashboard. Testing on sandbox won't affect your live data or create money movements.

Before using the API, reach out and get your Resolve account created. This account enables access to the credentials that are necessary for API access.

Resolve uses HTTP basic authentication where the username refers to your merchant ID, and the password refers to your secret API key.

When backwards-incompatible changes are released, a new, dated version is released. The current version is V5. You can upgrade the version of the api that your account uses within your merchant settings.

Legacy (v2) API documentation may be found here.

All top-level API resources have support for bulk fetches via "list" API methods. For instance, you can list customers, list invoices.

These list API methods share a common structure, taking at least two parameters: limit and page.

• count - represents total amount of records, satisfying the request query.
• page - a multiplier value, which gets applied to the limit and shows what position records are being returned from. For example, if limit = 20 and page = 5, then maximun 20 records will be returned from position 5 * 20 = 100.
• limit - maximun amount of records, which can be returned.
• results - array of records being returned. If no records satisfy request condition, the array will be empty.

To ensure platform reliability and fair use, Resolve implements rate limits for the REST API.

Resolve APIs use the Sliding Window algorithm to monitor and control request rates with a 100 requests/minute limit. The API will return a 429 Too Many Requests status if the amount of requests exceeds rate limits.

All responses from Resolve APIs will include the following headers:

• X-Ratelimit-Limit: The maximum amount of requests permitted within a 60-second period.
• X-Ratelimit-Remaining: The remaining requests within the current period.
• X-Ratelimit-Reset: A UNIX timestamp indicating when the rate limit period will reset.

Best Practices

• Use caching when necessary for data that is routinely requested by your application.
• Utilize the X-Ratelimit-Limit and X-Ratelimit-Remaining response headers in your application to avoid surpassing rate limits.
• Your application should avoid making additional API requests if your requests return with a 429 status code.

Webhooks allow you to receive real-time notifications about events in your Resolve account. When an event occurs, Resolve sends an HTTP POST request to your configured webhook endpoint with details about the event.

All webhook events follow a consistent structure:

{
  "id": "4ecbe7f9e8c1c9092c000027",
  "object": "invoice",
  "type": "invoice.created",
  "occurred_at": "2021-05-20T09:23:53+00:00",
  "data": {
    "id": "RH5fF9aeQ"
  }
}

The data.id field contains the ID of the object related to the event. You can use this ID to fetch the full object via the corresponding API endpoint.

Invoice Events

• invoice.created - Triggered when a new invoice record is created.
• invoice.balance_updated - Triggered when the outstanding balance of an invoice changes (for example, when a payment or credit note is applied).

Customer Events

• customer.created - Triggered when a new customer record is created.
• customer.status_updated - Triggered when a customer's status changes (for example, when a customer is submitted for a credit check or enrolled).
• customer.line_amount_updated - Triggered when a customer's credit limit amount is updated.
• customer.advance_rate_updated - Triggered when a customer's advance rate percentage is updated.
• customer.credit_decision_created - Triggered when a new credit decision is created for a customer.

Payout Events

• payout.created - Triggered when a new payout record is created.
• payout.status_changed - Triggered when the status of a payout changes (for example, pending, in transit, paid).

To ensure webhook requests are genuine and coming from Resolve, you should verify the webhook signature. Resolve includes a signature in the x-webhook-signature header of each webhook request.

JavaScript Example

const crypto = require('crypto');

function verifyWebhookSignature(payload, signature, secret) {
  const computedSignature = crypto
    .createHmac('sha256', secret)
    .update(JSON.stringify(payload))
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(computedSignature)
  );
}

// Usage in Express.js
app.post('/webhooks', express.json(), (req, res) => {
  const signature = req.headers['x-webhook-signature'];
  const isValid = verifyWebhookSignature(req.body, signature, process.env.WEBHOOK_SECRET);

  if (!isValid) {
    return res.status(401).send('Invalid signature');
  }

  // Process the webhook event
  const event = req.body;
  console.log('Received event:', event.type);

  res.status(200).send('Webhook received');
});

If your webhook endpoint doesn't respond successfully (non-2xx status code or connection error), Resolve will automatically retry sending the webhook notification. The retry schedule follows an exponential backoff pattern:

• 1st retry: 30 seconds after the initial attempt
• 2nd retry: 90 seconds after the 1st retry
• 3rd retry: 270 seconds (4.5 minutes) after the 2nd retry
• 4th retry: 810 seconds (13.5 minutes) after the 3rd retry
• 5th retry: 2430 seconds (40.5 minutes) after the 4th retry

After the 5th unsuccessful attempt, Resolve will stop retrying and the webhook delivery will be marked as failed.

• Always verify webhook signatures to ensure the request is from Resolve
• Respond with a 200 status code as quickly as possible to acknowledge receipt
• Process webhook events asynchronously if they require time-intensive operations
• Implement idempotency on your endpoint to handle duplicate events from retries
• Use the event id to track which events you've already processed

The invoice represents the business transaction between you and your customer. In Resolve, an invoice must be tied to a customer and an advance can be taken on the invoice.

For an advance to be taken on the invoice, a PDF of the invoice must be uploaded and the associated customer must be approved and have available credit for the amount of the invoice.

A customer represents a company that you do business with. For larger companies, there may be several users with access to the customer account that can make purchases with their credit line. For smaller companies, a customer may represent a single individual. Retrieve a customer to get a summary of their total credit line and available credit balance.