Integration Documentation
Everything you need to connect your systems to myapimonitor – from first request to production forwarding.
Overview
myapimonitor gives you public HTTPS endpoints that receive webhooks and API requests on your behalf. Every incoming request is logged, inspected and – if you set up rules – validated before it optionally gets forwarded to your target system.
This is not a classic REST-API reference. It is an integration guide that shows you how to connect your source systems (shops, ERPs, external services) to myapimonitor and how to make the most of validation, geocoding and forwarding.
Quickstart
Get up and running in under two minutes.
1. Create an endpoint
Open the dashboard, go to Endpoints and click Create endpoint. Give it a name and an optional slug (e.g. my-shop-orders). You will receive a unique URL like:
https://hooks.myapimonitor.com/my-shop-orders2. Send test data
Use curl, Postman or any HTTP client to send a JSON payload to your endpoint:
curl -X POST https://hooks.myapimonitor.com/my-shop-orders \
-H "Content-Type: application/json" \
-d '{"order_id": "12345", "customer": "Jane Doe", "total": 59.90}'3. Check the request
Go to Requests in the sidebar. You will see the incoming request with its full headers, body and timestamp.
4. Add a validation rule (optional)
Navigate to Rules and create a Required Fields rule for your endpoint. The next request that is missing a required field will appear in Alerts.
5. Enable forwarding (optional)
Open your endpoint settings and enable forwarding. Enter the URL of your target system. Valid requests will automatically be forwarded.
Send Requests
Send data to your endpoint URL using any HTTP method (POST, PUT, PATCH). The most common format is JSON, but XML, form data and plain text are also supported.
JSON via curl
curl -X POST https://hooks.myapimonitor.com/my-shop-orders \
-H "Content-Type: application/json" \
-d '{
"order_id": "12345",
"customer": "Jane Doe",
"items": [
{"sku": "A100", "qty": 2},
{"sku": "B200", "qty": 1}
],
"total": 59.90
}'XML via curl (optional)
curl -X POST https://hooks.myapimonitor.com/my-shop-orders \
-H "Content-Type: application/xml" \
-d '<order>
<order_id>12345</order_id>
<customer>Jane Doe</customer>
<total>59.90</total>
</order>'Postman
In Postman, set the request method to POST, paste your endpoint URL, select the Body tab, choose raw → JSON and paste your payload. Click Send.
Address payload example
If you use address validation or geocoding, send the address fields as flat keys or nested objects. The recommended field names are:
street, house_number, postal_code, city, country (ISO 2-letter code)
curl -X POST https://hooks.myapimonitor.com/my-shop-orders \
-H "Content-Type: application/json" \
-d '{
"order_id": "12345",
"customer": "Jane Doe",
"shipping_address": {
"street": "Hauptstraße",
"house_number": "42",
"postal_code": "10115",
"city": "Berlin",
"country": "DE"
}
}'Response Format
Every request to your endpoint returns a JSON response with status information and rule results.
HTTP status codes
- 202 202 Accepted – Request was received and processed successfully.
- 401 401 Unauthorized – Authentication failed (wrong API key, missing Bearer token, etc.).
- 403 403 Forbidden – Endpoint is disabled.
- 404 404 Not Found – Endpoint URL does not exist.
Response body
The response always includes the endpoint identifier, a status field and an array of rule results:
{
"status": "received",
"endpoint": "my-shop-orders",
"rules": [
{
"rule_id": 1,
"rule_name": "required_fields",
"result": "pass",
"errors": []
}
],
"forwarded": null
}If validation rules or geocoding checks are attached to the endpoint, their results appear in the rules array. Each entry shows the rule name, result (pass or fail) and any error messages.
When forwarding is enabled, the response also includes a forwarded object with the target's HTTP status code and response body (truncated to 2 000 characters).
Validation & Rules
Rules let you define what a valid request looks like. Every incoming request is checked against all rules attached to the endpoint. Results are logged and visible in Requests and Alerts.
Rule types
Required Fields – Check that specific fields are present in the payload. Supports dot notation for nested paths (e.g. address.city).
Required Headers – Ensure certain HTTP headers are included in the request (case-insensitive).
Schema Validation – Verify field types (string, number, boolean) against a defined schema.
Field Validation – Generic checks including type validation, pattern matching and value comparisons.
Address Validation – Local completeness checks and optional geocoding verification for postal addresses.
Forwarding – Forward the payload to an external URL and treat the response as a pass/fail signal.
When does a request pass?
A request passes when all attached rules return "pass". If any rule fails, the request is marked accordingly and – if notifications are enabled on the rule – an alert email is sent.
Alerts vs. warnings
Every rule failure creates an alert entry. You can find all alerts in the Alerts view, filtered by endpoint, rule or time range. If email notifications are enabled on a rule, the rule owner and optionally the team receive an email immediately.
Conditions
Conditions let you control when a rule is executed. Instead of running every rule on every request, you can define up to two conditions that must be met before the rule kicks in. This is especially useful to optimize API quotas – for example, you can run address geocoding only when the carrier is DHL.
How conditions work
Each condition checks a field in the incoming payload against a value. You can combine up to two conditions with AND (both must match) or OR (at least one must match). If no conditions are set, the rule runs on every request. If conditions are not met, the rule is silently skipped.
Available operators
equals– Field value must exactly match the condition value.not_equals– Field value must differ from the condition value.contains– Field value must contain the condition value as a substring.not_contains– Field value must not contain the condition value.exists– Field must be present in the payload (value is ignored).not_exists– Field must not be present in the payload.
Example
A geocoding rule with the condition "carrier equals DHL" will only verify the address when the carrier field in the payload is set to "DHL". All other requests will skip this rule.
Geocoding
The address validation rule can optionally verify addresses against a geocoding provider. This section explains how to get the best results.
Recommended fields
For the most accurate results, send the following fields:
street– Street name without house numberhouse_number– House number (separate from street for better accuracy)postal_code– ZIP or postal codecity– City namecountry– ISO 3166-1 alpha-2 country code (e.g. DE, US, FR)
Minimum requirements
At least two of the following must be present: street, postal_code, city. If fewer are provided, the address is rejected locally without making an API call.
Result classification
All important fields match with high confidence.
A match was found but something is off (e.g. postal code does not match city, house number unclear).
No usable match from the geocoding provider.
Pre-validation failed (too few fields or missing data).
Reason codes for suspicious results
POSTCODE_CITY_MISMATCHPostal code does not match the city.HOUSE_NUMBER_UNCLEARStreet was found but house number is ambiguous.COARSE_AREA_HITOnly an area-level match, not a precise address.LOW_CONFIDENCEMatch exists but confidence is below threshold.ROAD_NOT_FOUNDStreet name does not match.COUNTRY_MISMATCHCountry code does not match the resolved location.
What if the result is suspicious?
A suspicious result does not block the request by default. It creates an alert so you can review the address manually. You decide whether to forward the request or correct the data at the source.
Forwarding
Forwarding sends the original request payload to an external URL after validation. This lets you use myapimonitor as a validation and monitoring layer between your source and target systems.
When is a request forwarded?
Forwarding happens when the endpoint has forwarding enabled and a forwarding rule is attached. The original payload and headers (excluding host and content-length) are sent to the configured target URL.
Original or transformed data?
The original request body is forwarded as-is. myapimonitor does not transform or modify the payload. Custom headers can be added via the rule configuration.
Error handling
If the target system returns an HTTP status code ≥ 400 or is unreachable, the forwarding rule result is set to "fail". The error is logged and an alert is created if notifications are enabled.
Retries
There is currently no automatic retry mechanism. A failed forwarding attempt is logged and visible in Deliveries and Alerts. You can re-send from the source system or investigate the error in the dashboard.
Timeout
Forwarding requests have a timeout of 30 seconds. If the target system does not respond within this window, the forwarding is treated as failed.
Errors
This section lists common errors you may encounter when integrating with myapimonitor.
| Error | Possible cause | Solution |
|---|---|---|
404 Not Found | The endpoint URL or slug does not exist. | Check the endpoint URL in your dashboard. Make sure the slug has not been changed. |
401 Unauthorized | Authentication failed. | Verify your API key, Bearer token or Basic credentials. Check the auth configuration on the endpoint. |
403 Forbidden | The endpoint is disabled. | Enable the endpoint in the dashboard. |
Rule fail: missing fields | Required fields are not present in the payload. | Check the rule configuration to see which fields are required. Make sure your payload includes all of them. |
Rule fail: schema mismatch | A field has the wrong type (e.g. string instead of number). | Compare your payload against the schema defined in the rule. |
Rule fail: address not_found | The geocoding provider could not resolve the address. | Verify the address fields. Make sure street, postal_code and city are correct and the country code is a valid ISO 2-letter code. |
Forwarding fail: timeout | The target system did not respond within 30 seconds. | Check the availability of the target system. Consider increasing the response time on the target side. |
Forwarding fail: HTTP 5xx | The target system returned a server error. | Check the target system logs. The error response body is visible in the Deliveries view. |
Examples
Complete request examples you can copy and adapt for your integration.
Simple JSON request
A minimal order payload sent to your endpoint:
curl -X POST https://hooks.myapimonitor.com/my-shop-orders \
-H "Content-Type: application/json" \
-d '{
"order_id": "ORD-2025-0042",
"customer": "Jane Doe",
"email": "jane@example.com",
"items": [
{"sku": "WIDGET-A", "qty": 2, "price": 19.95},
{"sku": "GADGET-B", "qty": 1, "price": 20.00}
],
"total": 59.90,
"currency": "EUR"
}'Request with address data
An order with a full shipping address for geocoding validation:
curl -X POST https://hooks.myapimonitor.com/my-shop-orders \
-H "Content-Type: application/json" \
-d '{
"order_id": "ORD-2025-0043",
"customer": "Max Mustermann",
"email": "max@example.com",
"shipping_address": {
"street": "Berliner Straße",
"house_number": "123",
"postal_code": "10115",
"city": "Berlin",
"country": "DE"
},
"items": [{"sku": "WIDGET-A", "qty": 1}],
"total": 19.95
}'XML request
If your source system sends XML, set the Content-Type to application/xml:
curl -X POST https://hooks.myapimonitor.com/my-shop-orders \
-H "Content-Type: application/xml" \
-d '<order>
<order_id>ORD-2025-0044</order_id>
<customer>Jane Doe</customer>
<email>jane@example.com</email>
<items>
<item><sku>WIDGET-A</sku><qty>2</qty></item>
</items>
<total>39.90</total>
</order>'Checking results
After sending a request, you can verify the result in the dashboard:
- 📥 Requests – See all incoming requests with headers, body and timestamp.
- 🔔 Alerts – View rule failures and error details.
- 📤 Deliveries – Track forwarded requests and target system responses.
- 🔍 Use the search bar to filter by endpoint, payload content or error message.