RapidAPI Quickstart

Run This First

Get your RapidAPI key, make one request, and confirm the API is returning real audit data.

Overview

Start by proving the connection works. Once you can make one successful request, the rest of the API is straightforward.

Not Ready to Integrate Yet?

If you only need a one-time result, use a fixed-output Veldica report instead:

Need a One-Time Readable Report?

Use the Email Domain Trust Audit when you want one domain reviewed for SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, BIMI, risk notes, and prioritized next steps. Use the API when the same checks need to run repeatedly inside your own workflow.

First Steps

Follow a short sequence to verify the key, host, and response path.

  1. Pick a plan on the RapidAPI listing.
  2. Copy your X-RapidAPI-Key from the code section.
  3. Run the free audit request below against example.com.
  4. If you get a 200 OK response, you are ready to use the Pro tools.

Common Mistakes

Avoid the common setup mistakes that waste the first test request.

  • Send requests through RapidAPI, not directly to the API host.
  • {'Include the content-type': 'application/json header.'}
  • Use your RapidAPI key, not your Veldica site login.
  • Keep the request on the same RapidAPI account that owns the subscription.

Run this exact check first

Start with the free audit. It confirms your setup is correct without using any of your paid credits.

Request

curl -H 'content-type: application/json' \
  -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  -H 'X-RapidAPI-Host: email-domain-trust-auditor.p.rapidapi.com' \
  -X POST 'https://email-domain-trust-auditor.p.rapidapi.com/v1/free/audits/domain' \
  -d '{
  "domain": "example.com"
}'

Success looks like this

A successful call returns a 200 OK response with audit data you can trust.

Expected Result

This shape tells you the listing, key, and request body are all wired correctly.

HTTP/1.1 200 OK
X-Audit-Score: 95
X-Audit-Grade: A+
X-Audit-Units-Consumed: 0

{
  "audit_id": "eba3de04-9956-4b62-bcb8-23b82eabba1d",
  "domain": "example.com",
  "score": 95,
  "grade": "A+",
  "risk_level": "low",
  "enforcement_status": "partial",
  "mail_flow_profile": "apex_non_mail_protected",
  "mail_flow_note": "The apex publishes null MX and SPF -all. Treat the score as protective DNS posture for a non-mail apex, not active sender-program readiness.",
  "assessment_confidence": "high",
  "coverage_summary": "The apex appears intentionally configured as a non-mail domain (null MX + SPF -all). Interpret the score as protective DNS posture, not active sender-program readiness.",
  "top_findings": [
    {
      "id": "dmarc.missing_rua",
      "check": "dmarc",
      "severity": "medium"
    }
  ],
  "top_recommendations": [
    "Add rua=mailto:<monitored-dmarc-report-mailbox> to receive aggregate reports."
  ]
}

Tips for Developers

These are the first checks I would make before wiring the response into a workflow.

  • Start with example.com: It is a clean way to test the request flow before using a real domain.
  • Skip selectors at first: Add them later when you need full DKIM checks.
  • Track usage: Watch the X-Audit-Units-Consumed header to understand your request cost.
  • Use Free for testing: It is the safest way to validate internal checks and build steps.

What to do next

Once the request is working, these are the next useful paths.

  1. Run a full Pro Audit on a domain you own.
  2. Generate a Fix Plan from the result.
  3. Audit the same domain again after your DNS update.
  4. Build a report you can share with a teammate or client.

Keep Exploring

Use the Workflow Library to browse more guides, comparisons, and integration examples to continue your evaluation.

Connection Working?

Once the request is working, the full docs and workflow pages are worth the next step.