{
"data": {
"active": true
},
"status": true,
"message": "Integration status updated",
"appended_data": []
}{
"status": false,
"message": "Invalid or inactive API key",
"appended_data": {}
}{
"status": false,
"message": "The given data was invalid.",
"appended_data": {},
"errors": {
"total_price": [
"The total price field is required."
],
"products.0.quantity": [
"The quantity must be at least 1."
]
}
}Toggle integration active state
Mirrors the merchant’s external-platform toggle (Matajer’s “ربط بوينتس”
switch today, any other channel tomorrow) into our DB. Flips the
integration_active flag on the API key that authenticated the
request — driving the green/red dot on our /merchants listing and
any business logic that needs to know “is this merchant currently
toggled on?”
Distinct from Key.status, which is the auth-validity flag (admin
can kill a leaked key without touching the merchant’s intent). The
two flags compose: a merchant is shown as active only when
both are true.
Idempotent — sending { "active": true } on an already-active key
(or vice-versa) is a no-op that still returns 200. Safe to retry.
{
"data": {
"active": true
},
"status": true,
"message": "Integration status updated",
"appended_data": []
}{
"status": false,
"message": "Invalid or inactive API key",
"appended_data": {}
}{
"status": false,
"message": "The given data was invalid.",
"appended_data": {},
"errors": {
"total_price": [
"The total price field is required."
],
"products.0.quantity": [
"The quantity must be at least 1."
]
}
}Authorizations
Body
true when the merchant just toggled the integration ON in the
external platform (Matajer's "ربط بوينتس" switch today),
false on toggle OFF.
true