Start
POST/schedule/:apiKey/start
Start a schedule.
Requires the registrationId
of an existing transaction of type Register, Debit (withRegister
), or Preauthorize (withRegister
).
Please be aware of the rate limit for this API endpoint:
- Total limit: Each unique API user is limited to to 60 requests per 60-second window.
If these limits are exceeded, the server will respond with a HTTP 429 status code, indicating too many requests. Please ensure to manage your requests within these limits to maintain uninterrupted service.
Request
Path Parameters
Possible values: <= 50 characters
API Key of Connector
- application/json
Body
required
Start a schedule on the given registration transaction
Possible values: <= 50 characters
Possible values: Value must match regular expression ^(([0-9]{1,10})|([0-9]{1,10}\.[0-9]{1,3}))$
Decimal amount separated by .
, maximum of 3 decimals.
Possible values: Value must match regular expression ^[A-Z]{3}$
ISO 4217 three-letter currency code.
Possible values: [DAY
, WEEK
, MONTH
, YEAR
]
The unit that the duration is measured in.
Possible values: Value must match regular expression ^[0-9]{4}-((0[1-9])|(1[0-2]))-((0[1-9])|([1-2][0-9])|(3[0-1]))T(([0-1][0-9])|([2][0-3])):([0-5][0-9]):([0-5][0-9])\+[0-9]{2}\:[0-9]{2}$
RFC 3339 Internet Date/Time Format date-time
Possible values: <= 255 characters
Possible values: <= 4096 characters
Callback URL for sending notifications of transactions initiated by the schedule, instead of the URL from the Register transaction.
Responses
- 200
- 429
Schedule response
- application/json
- Schema
- Example (from schema)
- Success
- Error
Schema
- false
- true
Possible values: [false
, true
]
Error message.
While the errorMessage
field provides useful context for understanding the nature of the error, it's important to note that the content of this message can vary based on specific circumstances.
For consistent and reliable error handling in your application, always base your logic on the errorCode
field, not the errorMessage
.
Possible values: [ACTIVE
, PAUSED
, CANCELLED
, ERROR
, CREATE-PENDING
, NON-EXISTING
]
Status of the schedule.
Possible values: [ACTIVE
, PAUSED
, CANCELLED
, ERROR
, CREATE-PENDING
, NON-EXISTING
]
Status of the schedule.
Possible values: Value must match regular expression ^[0-9]{4}-((0[1-9])|(1[0-2]))-((0[1-9])|([1-2][0-9])|(3[0-1]))T(([0-1][0-9])|([2][0-3])):([0-5][0-9]):([0-5][0-9])\+[0-9]{2}\:[0-9]{2}$
RFC 3339 Internet Date/Time Format date-time
{
"success": true
}
{
"success": true,
"scheduleId": "SC-1234-1234-1234-1234-1234-1234",
"registrationUuid": "abcde01234abcde01234",
"oldStatus": "NON-EXISTING",
"newStatus": "ACTIVE",
"scheduledAt": "2019-09-30T12:00:00+00:00"
}
{
"success": false,
"errorMessage": "The scheduleId is not valid or does not match to the connector",
"errorCode": 7040
}
Rate limit exceeded
- application/json
- Schema
- Example (from schema)
- Example
Schema
Possible values: [false
]
Returns true
or false
depending on whether the request was successful.
Error message.
While the errorMessage
field provides useful context for understanding the nature of the error, it's important to note that the content of this message can vary based on specific circumstances.
For consistent and reliable error handling in your application, always base your logic on the errorCode
field, not the errorMessage
.
{
"success": false,
"errorMessage": "string",
"errorCode": 0,
"details": "string"
}
{
"success": false,
"errorCode": 1009,
"errorMessage": "Too many requests"
}