For developers & agents
API documentation
SkaleWell publishes one public API: lead submission. It's documented here for
humans, as an OpenAPI 3.1 spec for tooling, and
discoverable automatically at
/.well-known/api-catalog per
RFC 9727.
Lead Submission API
Accepts a name, email and optional context (website, ad spend, message) from skalewell.com's contact and call-booking forms, and forwards it to SkaleWell's internal notification pipeline. This is the exact endpoint the site's own forms call — there is no separate "public" version.
Endpoint
Request body
multipart/form-data or application/x-www-form-urlencoded.
| Field | Type | Required | Notes |
|---|---|---|---|
name | string | Yes | Full name. |
email | string | Yes | Must be a valid email address. |
website | string | No | URL of the submitter's brand/store. |
spend | string | No | Free-text current/planned monthly ad spend. |
message | string | No | Free-text enquiry details. |
Example request
Responses
| Status | Body | Meaning |
|---|---|---|
200 | {"ok":true} | Accepted. See note below. |
422 | {"ok":false,"error":"invalid_input"} | Missing name or invalid email. |
405 | {"ok":false,"error":"method_not_allowed"} | Non-POST request. |
502 | {"ok":false,"error":"email_failed"} | Upstream email delivery failed. |
Honest note on 200 responses: a small number of anti-spam checks
(honeypot field, submission timing) are accepted silently as {"ok":true}
without ever being delivered to a human, so automated probing can't be used to
reverse-engineer the filter. Every submission that passes those checks is always
delivered in full — nothing that looks like a real enquiry is ever dropped.
Machine-readable resources
| Relation | Resource |
|---|---|
service-desc | /openapi.json — OpenAPI 3.1 spec |
service-doc | /api-docs.html — this page |
status | /api-status.php — health check |
api-catalog | /.well-known/api-catalog — RFC 9727 linkset |