Live chat support referred us here to investigate a public JSON-RPC API booking rejection observed on 21 September 2026. This report contains only generalized technical details; no credentials, patient/contact data, booking identifiers, or account-specific field hashes.
Observed behavior
Authentication, service/provider lists, getAdditionalFields(serviceId), and getStartTimeMatrix succeed.
getAdditionalFields returns two select fields, including one required field.
We pass each returned field.name hash as the additionalFields key and the exact corresponding allowed string from values, following your developer example.
book returns HTTP 200 with JSON-RPC error code -32070 and data: . The returned message is a generic Spanish booking/availability message, with no field-level explanation.
Three separately guarded technical tests returned the same rejection in approximately 14–15 seconds. No booking IDs were returned and the admin report filtered for the test contact/date showed no bookings.
Restricting additionalFields to ONLY those two fields returned by getAdditionalFields, without attribution fields, produced the same rejection.
Our booking timeout now allows 45 seconds; we do not automatically retry booking creation, and duplicate protection is preserved. The provider rejection persists independently of the previous timeout.
Expected behavior / questions
Please identify why a literal allowed select value keyed by the returned field.name can produce -32070, and how to obtain the exact failing field or rule.
Can required fields or account validation rules exist that getAdditionalFields(serviceId) does not expose?
Do select fields require another value format in some configurations, despite the documented example?
How should we provide the minimal account-specific reproduction securely to your engineering team? We can supply it through an approved private channel, not in this public thread.
Separately, the Manage > Intake forms page did not finish loading during investigation, with a timeout loading management/init.min.js. We have not established whether that is related to the API rejection.
Please investigate without disabling required fields or security/privacy controls. Thank you.
Thanks for the detailed report. It gave us enough to identify the cause without account data.
Short answer: the rejection most likely does not come from the select field validation. It comes from the External Booking Validator configured on this company account.
Why we think so:
When a select value itself is invalid, book returns -32070 with a message like " - ‘’ was not found in the haystack". This message names the field. A generic booking/availability message with empty data is not produced by our additional field validation.
When the External Booking Validator plugin is enabled, every book call sends a server-to-server POST to the validator URL set in the company settings, with a 15-second timeout. Your consistent ~14–15 s response time matches that timeout exactly. In practice this means one of two things:
the validator endpoint did not respond within 15 s (or returned a non-200 status). The API then returns -32070 with a generic “validation error” message (in Spanish: “¡Ops! Hay un error de validación.”), or
the validator responded with an errors array. We pass that text through unchanged as the -32070 message, so the Spanish availability wording would come from the validator itself.
Answers to your questions:
Why -32070 with a valid select value / how to find the failing rule.
The rule is on the validator side, not in SimplyBook.me. Please check the logs of the endpoint configured under Custom Features → External Booking Validator. If you control that endpoint, it can return field-level errors as additional_fields: [{ “id”: “”, “errors”: [“…”] }] instead of a top-level errors array. For visible fields, the API then includes field_error in the error data.
Hidden required fields/rules.
Yes. In the public API, getAdditionalFields(serviceId) returns only fields visible to clients. The External Booking Validator receives all fields of the service, including hidden ones (with their default values), plus service, provider, client, date/time, location/category and products. So it can apply rules you cannot see through the public API.
Select value format.
No other format is needed. The submitted value is checked against the comma-separated values list (trimmed, exact match), keyed by field.name. This is what you are already doing. The only edge case is an option label that itself contains a comma, since the list is split on commas.
Private reproduction.
Please send it to support@simplybook.me with a link to this thread and the company login. The approximate timestamps of the three test calls are enough for us to check server-side logs.
The Manage → Intake forms loading timeout (management/init.min.js) is unrelated to the API rejection. It is a front-end asset load, most likely a temporary network issue. If it keeps happening, please mention it in the same support email.
No need to disable required fields or security controls. The fix is in the validator endpoint: it needs to respond faster than 15 s, or accept this booking combination.