Website forms & inquiries

The website-form endpoint is the shortest path from a contact form to Henvendelser in Aventra. It imports or finds the company, creates or reuses a contact, saves the inquiry and sends email notifications to the recipients configured for that form.

Pick the right intake flow

Get a form URL

Ask Aventra to configure a form for your workspace. You will need:

• A form name and the form UUID used in the submission URL.
• The exact website origins that should be allowed to submit from a browser, including the protocol and any port.
• The email addresses that should receive inquiry notifications.

Form setup currently needs assistance from Aventra; there is no self-service form configuration screen. Use a separate form for each source when you want to distinguish inquiries in the CRM.

POST https://app.aventra.no/api/form/{formId}

This endpoint stays on the CRM application host. The documentation website is deployed separately and does not receive form submissions.

Send a submission

The body is JSON. meta is required, even when you have no attribution data; send {} in that case. Do not send an API key.

curl "https://app.aventra.no/api/form/$AVENTRA_FORM_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Ola Nordmann",
    "email": "ola@example.com",
    "organizationNumber": "923609016",
    "type": "demo",
    "message": "We would like a demo for our sales team.",
    "meta": {
      "utm_source": "website",
      "utm_campaign": "autumn-demo"
    }
  }'

The endpoint accepts meta.referrer, but currently does not save it. Do not rely on it for attribution.

Read the plain-text response

A successful response is HTTP 200 with the text OK, not JSON. It means the inquiry was saved. Email delivery is not guaranteed by this response, and a notification failure does not discard the inquiry.

const response = await fetch("https://app.aventra.no/api/form/YOUR_FORM_UUID", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    name: "Ola Nordmann",
    email: "ola@example.com",
    organizationNumber: "923609016",
    type: "demo",
    message: "We would like a demo.",
    meta: {},
  }),
});

const result = await response.text();
if (!response.ok) throw new Error(`Submission failed (${response.status}).`);
// Show the visitor a confirmation after the successful response.
console.log(result); // OK

These errors are separate from the CRM API's JSON error format.

Browser origins and spam protection

For browser submissions, the website's origin must match the configured allowed origins exactly. https://example.com and https://www.example.com are different origins. JSON requests trigger an OPTIONS preflight, which returns 204. The allowed request headers are Content-Type and X-Requested-With.

CORS controls browser access; it is not authentication or spam protection. A server can submit directly to a known form URL. For a public website, forwarding through your own server lets you validate submissions and apply rate limiting or bot protection before forwarding to Aventra. Never put a CRM API key in the browser as an alternative.

Existing contacts and retries

The current form flow matches existing contacts by their formatted name within the workspace. Two different people with the same name can therefore match the same contact. Use the CRM API intake walkthrough when you need your integration to control contact identity explicitly.

Every successful submission creates a new inquiry. There is no idempotency key and no inquiry ID in the response. Disable repeated form submissions while one is pending. After a timeout, check Henvendelser before resending; a failed or missing response does not guarantee that nothing was saved.

The company, contact, relationships and inquiry are separate writes. An inquiry can be saved even if adding a contact detail or relationship fails. Email notifications go to the form's configured recipients, not automatically to the person who submitted it.