Skip to main content

REST API

ਹਰ imatic ਉਤਪਾਦ ਇੱਕ ਵਰਜ਼ਨ ਕੀਤਾ REST API ਨਾਲ ਆਉਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਸ ਨੂੰ ਆਪਣੇ ਖ਼ੁਦ ਦੇ ਕੋਡ ਤੋਂ ਸਵੈਚਾਲਿਤ ਕਰ ਸਕੋ। ਇਸ ਪੰਨੇ ਦੇ ਨਿਯਮ — ਤੁਸੀਂ ਕਿਵੇਂ ਪ੍ਰਮਾਣਿਤ ਕਰਦੇ ਹੋ, API ਕੁੰਜੀਆਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਵੈੱਬਹੁੱਕ ਕਿਵੇਂ ਹਸਤਾਖਰਿਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਪੇਜੀਨੇਸ਼ਨ, ਰੇਟ ਸੀਮਾਵਾਂ, ਅਤੇ ਗ਼ਲਤੀਆਂ ਕਿਵੇਂ ਵਿਹਾਰ ਕਰਦੀਆਂ ਹਨ — ਉਤਪਾਦਾਂ ਵਿਚਕਾਰ ਇੱਕੋ ਜਿਹੇ ਹਨ। ਜੋ ਵੱਖਰਾ ਹੈ ਉਹ ਹਰ ਉਤਪਾਦ ਦੁਆਰਾ ਉਜਾਗਰ ਕੀਤੇ ਸਰੋਤ ਹਨ, ਜੋ ਇਸ ਦੇ ਡਿਵੈਲਪਰ ਪੰਨੇ 'ਤੇ ਦਸਤਾਵੇਜ਼ੀਕ੍ਰਿਤ ਹਨ।

ਉਦਾਹਰਨਾਂ ਦਰਸ਼ਨੀ ਹਨ

ਹੇਠਾਂ ਦਿੱਤੇ ਬੇਨਤੀ ਅਤੇ ਜਵਾਬ ਸਨਿੱਪਟ ਕਾਲਾਂ ਦਾ ਆਕਾਰ ਦਿਖਾਉਂਦੇ ਹਨ — ਹੈਡਰ, ਪ੍ਰਮਾਣੀਕਰਨ, ਗ਼ਲਤੀ ਲਿਫ਼ਾਫ਼ੇ — ਨਾ ਕਿ ਇੱਕ ਠੀਕ ਫੀਲਡ-ਦਰ-ਫੀਲਡ ਸਕੀਮਾ। ਕਿਸੇ ਉਤਪਾਦ ਦੇ ਸਟੀਕ ਅੰਤ-ਬਿੰਦੂਆਂ, ਪੈਰਾਮੀਟਰਾਂ, ਅਤੇ ਫੀਲਡ ਨਾਮਾਂ ਲਈ, ਉਸ ਉਤਪਾਦ ਦੇ ਡਿਵੈਲਪਰ ਪੰਨੇ ਦੇ ਲਿੰਕਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ।

ਪ੍ਰਮਾਣੀਕਰਨ​

imatic ਦੋ ਵੱਖ-ਵੱਖ ਕਾਲਰਾਂ ਲਈ, ਦੋ ਕਿਸਮ ਦੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਰਤਦਾ ਹੈ:

  • JWT (ਸੈਸ਼ਨ ਟੋਕਨ) — ਜੋ ਵੈੱਬ ਐਪ ਵਰਤਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਈਮੇਲ ਅਤੇ ਪਾਸਵਰਡ ਨਾਲ ਸਾਈਨ ਇਨ ਕਰਦੇ ਹੋ। ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਤੁਹਾਨੂੰ ਪ੍ਰਤੀਨਿਧਤ ਕਰਦਾ ਹੈ ਅਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਾਲਾ ਹੈ। ਤੁਸੀਂ ਇਸ ਨੂੰ ਸਿੱਧਾ ਪ੍ਰਬੰਧਿਤ ਨਹੀਂ ਕਰਦੇ; ਐਪ ਕਰਦੀ ਹੈ।
  • ਸਕੋਪ ਕੀਤੀ API ਕੁੰਜੀ — ਜੋ ਤੁਹਾਡਾ ਕੋਡ v1 REST API ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਵਰਤਦਾ ਹੈ। ਤੁਸੀਂ ਇਸ ਨੂੰ ਖ਼ੁਦ ਬਣਾਉਂਦੇ ਹੋ, ਇਹ ਸਪੱਸ਼ਟ ਸਕੋਪ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਸੈਸ਼ਨ ਨਾਲ ਖ਼ਤਮ ਨਹੀਂ ਹੁੰਦੀ।

ਸਰਵਰ-ਤੋਂ-ਸਰਵਰ ਕਾਲਾਂ ਲਈ, ਹਮੇਸ਼ਾ ਇੱਕ API ਕੁੰਜੀ ਵਰਤੋ — ਕਦੇ ਆਪਣਾ ਪਾਸਵਰਡ ਜਾਂ ਕਾਪੀ ਕੀਤਾ ਸੈਸ਼ਨ ਟੋਕਨ ਨਹੀਂ।

ਇੱਕ API ਕੁੰਜੀ ਭੇਜਣਾ​

ਕੁੰਜੀ ਨੂੰ Authorization ਹੈਡਰ ਵਿੱਚ ਇੱਕ Bearer ਟੋਕਨ ਵਜੋਂ ਪਾਸ ਕਰੋ:

curl https://<product-host>/v1/event-types \
  -H "Authorization: Bearer cal_abc123.s3cr3t_keymaterial" \
  -H "Content-Type: application/json"

API ਕੁੰਜੀਆਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ​

ਤੁਸੀਂ ਹਰ ਉਤਪਾਦ ਦੇ ਡਿਵੈਲਪਰ ਖੇਤਰ ਵਿੱਚ API ਕੁੰਜੀਆਂ ਬਣਾਉਂਦੇ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਦੇ ਹੋ — ਉਦਾਹਰਨ ਲਈ Calendar ਦਾ Developers → API keys ਅਤੇ Survey ਦਾ Developers → API keys। ਇੱਕ ਕੁੰਜੀ ਦੇ ਤਿੰਨ ਗੁਣ ਹਨ ਜੋ ਸਮਝਣ ਯੋਗ ਹਨ:

  • prefix.secret ਫਾਰਮੈਟ — ਇੱਕ ਕੁੰਜੀ ਵਿੱਚ ਇੱਕ ਜਨਤਕ ਪ੍ਰੀਫ਼ਿਕਸ ਅਤੇ ਇੱਕ ਰਾਜ਼ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ, ਇੱਕ ਬਿੰਦੀ ਨਾਲ ਜੁੜੇ (ਉਦਾਹਰਨ ਲਈ cal_abc123.s3cr3t_keymaterial — Calendar ਕੁੰਜੀਆਂ ਇੱਕ ਛੋਟਾ cal_ ਪ੍ਰੀਫ਼ਿਕਸ ਵਰਤਦੀਆਂ ਹਨ)। ਪ੍ਰੀਫ਼ਿਕਸ imatic ਨੂੰ ਸੂਚੀਆਂ ਅਤੇ ਲੌਗਾਂ ਵਿੱਚ ਕੁੰਜੀ ਦੀ ਪਛਾਣ ਕਰਨ ਦਿੰਦਾ ਹੈ; ਰਾਜ਼ ਉਹ ਹੈ ਜੋ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਤੁਹਾਡੀ ਹੈ।
  • ਇੱਕ ਵਾਰ ਦਿਖਾਇਆ ਗਿਆ — ਪੂਰਾ ਕੁੰਜੀ ਮੁੱਲ ਸਿਰਫ਼ ਉਸ ਪਲ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਬਣਾਉਂਦੇ ਹੋ। ਉਸ ਤੋਂ ਬਾਅਦ, ਸਿਰਫ਼ ਪ੍ਰੀਫ਼ਿਕਸ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
  • ਸਕੋਪ — ਹਰ ਕੁੰਜੀ ਉਨ੍ਹਾਂ ਕਾਰਵਾਈਆਂ ਤੱਕ ਸੀਮਤ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਇਸ ਨੂੰ ਦਿੰਦੇ ਹੋ। Calendar ਦੇ ਸਕੋਪ slots:read, bookings:read, bookings:write, ਅਤੇ mcp ਹਨ (mcp ਸਕੋਪ ਉਹ ਹੈ ਜਿਸ ਦੀ ਕਿਸੇ AI ਏਜੰਟ ਦੀ ਕੁੰਜੀ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ — ਦੇਖੋ AI ਏਜੰਟਾਂ ਲਈ MCP)। ਇੱਕ ਬੇਨਤੀ ਜੋ ਕੁੰਜੀ ਦੇ ਸਕੋਪ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਉਸ ਨੂੰ ਅਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
API ਕੁੰਜੀਆਂ ਨੂੰ ਪਾਸਵਰਡਾਂ ਵਾਂਗ ਸਮਝੋ

ਕਿਸੇ ਕੁੰਜੀ ਦਾ ਰਾਜ਼ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ, ਬਣਾਉਣ ਵੇਲੇ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ। ਉਦੋਂ ਇਸ ਨੂੰ ਕਾਪੀ ਕਰੋ ਅਤੇ ਇੱਕ ਸੀਕ੍ਰੇਟ ਮੈਨੇਜਰ ਜਾਂ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਵਿੱਚ ਸਟੋਰ ਕਰੋ — ਕਦੇ ਸੋਰਸ ਕੰਟਰੋਲ, ਇੱਕ ਸਕ੍ਰੀਨਸ਼ਾਟ, ਜਾਂ ਇੱਕ ਸਾਂਝੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਹੀਂ। ਜੇ ਕੋਈ ਕੁੰਜੀ ਉਜਾਗਰ ਹੋ ਜਾਵੇ, ਤਾਂ ਡਿਵੈਲਪਰ ਖੇਤਰ ਵਿੱਚ ਇਸ ਨੂੰ ਰੱਦ ਕਰੋ ਅਤੇ ਇੱਕ ਬਦਲਵੀਂ ਬਣਾਓ। ਰੱਦ ਕਰਨਾ ਤੁਰੰਤ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

ਵੈੱਬਹੁੱਕ​

ਤਬਦੀਲੀਆਂ ਲਈ ਪੋਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਇੱਕ ਵੈੱਬਹੁੱਕ URL ਰਜਿਸਟਰ ਕਰੋ ਅਤੇ imatic ਉਸ ਨੂੰ ਇੱਕ ਇਵੈਂਟ POST ਕਰੇਗਾ ਜਦੋਂ ਕੁਝ ਵਾਪਰਦਾ ਹੈ — ਉਦਾਹਰਨ ਲਈ Calendar ਵਿੱਚ ਕੋਈ ਬੁਕਿੰਗ ਬਣਦੀ ਹੈ ਜਾਂ Survey ਵਿੱਚ ਕੋਈ ਜਵਾਬ ਜਮ੍ਹਾਂ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਹਰ ਉਤਪਾਦ ਦੇ Developers → Webhooks ਖੇਤਰ ਵਿੱਚ ਵੈੱਬਹੁੱਕ ਅੰਤ-ਬਿੰਦੂ ਪ੍ਰਬੰਧਿਤ ਕਰਦੇ ਹੋ, ਜਿੱਥੇ ਤੁਸੀਂ ਇੱਕ ਟੈਸਟ ਡਿਲੀਵਰੀ ਵੀ ਭੇਜ ਸਕਦੇ ਹੋ।

ਇੱਕ ਡਿਲੀਵਰੀ ਮੋਟੇ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦੀ ਹੈ:

POST /your/webhook/endpoint HTTP/1.1
Content-Type: application/json
X-Imatic-Signature: t=1718900000,v1=9f86d081884c7d659a2feaa0c55ad015...

{
  "event": "booking.created",
  "data": { "...": "event-specific payload" }
}

ਹਸਤਾਖਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ​

ਹਰ ਡਿਲੀਵਰੀ ਤੁਹਾਡੇ ਅੰਤ-ਬਿੰਦੂ ਦੇ ਹਸਤਾਖਰ ਰਾਜ਼ ਨਾਲ HMAC-SHA256 ਵਰਤ ਕੇ, ਇੱਕ Stripe-ਸ਼ੈਲੀ X-Imatic-Signature ਹੈਡਰ ਵਿੱਚ ਹਸਤਾਖਰਿਤ ਹੁੰਦੀ ਹੈ। ਹੈਡਰ ਦੋ ਫੀਲਡ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ: t, ਭੇਜਣ ਦੇ ਸਮੇਂ ਦੇ unix-epoch ਸਕਿੰਟ, ਅਤੇ v1, ਸਟ੍ਰਿੰਗ ${t}.${body} (ਟਾਈਮਸਟੈਂਪ, ਇੱਕ ਅੱਖਰੀ ਬਿੰਦੀ, ਫਿਰ ਠੀਕ ਕੱਚਾ ਬੇਨਤੀ ਬਾਡੀ) ਦਾ ਹੈਕਸ HMAC। ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ, ਹੈਡਰ ਨੂੰ ਵੰਡੋ, ਆਪਣੇ ਹਸਤਾਖਰ ਰਾਜ਼ ਨਾਲ t + "." + rawBody ਉੱਤੇ v1 ਦੁਬਾਰਾ ਗਣਨਾ ਕਰੋ, ਅਤੇ ਇਕਸਾਰ ਸਮੇਂ (constant time) ਵਿੱਚ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਮੇਲ ਨਾ ਖਾਣ ਤਾਂ ਅਸਵੀਕਾਰ ਕਰੋ — ਅਤੇ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ ਅਸਵੀਕਾਰ ਕਰੋ ਜਦੋਂ t ਕੁਝ ਮਿੰਟਾਂ ਤੋਂ ਪੁਰਾਣਾ ਹੋਵੇ ਤਾਂ ਜੋ ਰੀਪਲੇ ਤੋਂ ਬਚਾਅ ਹੋ ਸਕੇ।

import crypto from "node:crypto";

function isValid(rawBody, signatureHeader, signingSecret) {
  // Header shape: "t=<epoch-seconds>,v1=<hex hmac>"
  const parts = Object.fromEntries(
    signatureHeader.split(",").map((kv) => kv.split("=")),
  );
  const { t, v1 } = parts;
  if (!t || !v1) return false;

  // Sign the timestamped body: `${t}.${rawBody}` — NOT the raw body alone.
  const expected = crypto
    .createHmac("sha256", signingSecret)
    .update(`${t}.${rawBody}`)
    .digest("hex");

  // Constant-time comparison to avoid timing attacks.
  const a = Buffer.from(v1);
  const b = Buffer.from(expected);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
ਹਰ ਉਤਪਾਦ ਅਨੁਸਾਰ ਸਟੀਕ ਸਕੀਮ

ਉੱਪਰ ਦਿੱਤੀ t=…,v1=… ਸਕੀਮ Calendar ਦੀ ਹੈ। ਇੱਕ ਵੈਰੀਫ਼ਾਇਰ ਸ਼ਿੱਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਉਤਪਾਦ ਦੇ ਡਿਵੈਲਪਰ ਪੰਨੇ 'ਤੇ ਹੈਡਰ ਨਾਮ, ਫੀਲਡ, ਅਤੇ ਹਸਤਾਖਰਿਤ ਸਟ੍ਰਿੰਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਛੇਤੀ ਜਵਾਬ ਦਿਓ, ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰੋ

ਪ੍ਰਾਪਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਛੇਤੀ ਇੱਕ 2xx ਵਾਪਸ ਕਰੋ, ਫਿਰ ਕੋਈ ਵੀ ਹੌਲਾ ਕੰਮ ਅਸਿੰਕ੍ਰੋਨਸ ਢੰਗ ਨਾਲ ਕਰੋ। ਜੇ ਤੁਹਾਡਾ ਅੰਤ-ਬਿੰਦੂ ਹੌਲਾ ਹੈ ਜਾਂ ਗ਼ਲਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਡਿਲੀਵਰੀਆਂ ਦੁਬਾਰਾ ਅਜ਼ਮਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

ਪੇਜੀਨੇਸ਼ਨ​

ਸੂਚੀ ਅੰਤ-ਬਿੰਦੂ ਨਤੀਜੇ ਪੰਨਿਆਂ ਵਿੱਚ ਵਾਪਸ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਇੱਕ ਕਾਲ ਨੂੰ ਕਦੇ ਸਭ ਕੁਝ ਲੋਡ ਨਾ ਕਰਨਾ ਪਵੇ। ਬੇਨਤੀ 'ਤੇ ਪੇਜਿੰਗ ਪੈਰਾਮੀਟਰ ਪਾਸ ਕਰੋ ਅਤੇ ਅਗਲਾ ਪੰਨਾ ਲੈਣ ਲਈ ਜਵਾਬ 'ਤੇ ਪੇਜਿੰਗ ਮੈਟਾਡੇਟਾ ਪੜ੍ਹੋ।

curl "https://<product-host>/v1/bookings?limit=25" \
  -H "Authorization: Bearer cal_abc123.s3cr3t_keymaterial"
{
  "success": true,
  "data": [ { "...": "one item per result" } ],
  "pagination": { "page": 1, "limit": 20, "total": 0, "pages": 0 }
}

ਉਦੋਂ ਤੱਕ ਅਗਲਾ ਪੰਨਾ ਮੰਗਦੇ ਰਹੋ ਜਦੋਂ ਤੱਕ ਹੋਰ ਨਤੀਜੇ ਨਾ ਹੋਣ।

ਰੇਟ ਸੀਮਾ​

ਪਲੇਟਫਾਰਮ ਨੂੰ ਨਿਰਪੱਖ ਅਤੇ ਸਥਿਰ ਰੱਖਣ ਲਈ API ਕੁੰਜੀਆਂ ਰੇਟ-ਸੀਮਤ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦੇ ਹੋ, ਤਾਂ API HTTP 429 Too Many Requests ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਅੰਤ-ਬਿੰਦੂ ਨੂੰ ਖਟਖਟਾਉਣ ਦੀ ਬਜਾਏ ਪਿੱਛੇ ਹਟੋ ਅਤੇ ਦੁਬਾਰਾ ਅਜ਼ਮਾਓ — ਆਦਰਸ਼ ਤੌਰ 'ਤੇ ਘਾਤਾਂਕੀ ਬੈਕ-ਆਫ਼ ਅਤੇ jitter ਨਾਲ।

{
  "success": false,
  "error": "rate_limited",
  "message": "Too many requests. Please retry after a short delay."
}

ਗ਼ਲਤੀ ਪ੍ਰਬੰਧਨ​

ਗ਼ਲਤੀਆਂ ਮਿਆਰੀ HTTP ਸਥਿਤੀ ਕੋਡ ਨਾਲ ਇੱਕ JSON ਬਾਡੀ ਵਰਤਦੀਆਂ ਹਨ ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਕੀ ਗ਼ਲਤ ਹੋਇਆ। ਉਹ ਕੋਡ ਜੋ ਤੁਸੀਂ ਸਭ ਤੋਂ ਅਕਸਰ ਦੇਖੋਗੇ:

  • 400 — ਬੇਨਤੀ ਖ਼ਰਾਬ ਸੀ ਜਾਂ ਪੁਸ਼ਟੀਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹੀ।
  • 401 — ਗ਼ੈਰ-ਮੌਜੂਦ ਜਾਂ ਅਵੈਧ API ਕੁੰਜੀ।
  • 403 — ਕੁੰਜੀ ਵੈਧ ਹੈ ਪਰ ਇਸ ਕਾਰਵਾਈ ਲਈ ਸਕੋਪ (ਜਾਂ org ਪਹੁੰਚ) ਦੀ ਘਾਟ ਹੈ।
  • 404 — ਸਰੋਤ ਮੌਜੂਦ ਨਹੀਂ ਹੈ ਜਾਂ ਇਸ ਕੁੰਜੀ ਨੂੰ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦਾ।
  • 409 — ਇੱਕ ਟਕਰਾਅ, ਜਿਵੇਂ ਕਿ ਉਸ ਸਲਾਟ ਨੂੰ ਬੁੱਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਜੋ ਹੁਣੇ ਲੈ ਲਿਆ ਗਿਆ ਸੀ।
  • 429 — ਰੇਟ-ਸੀਮਤ; ਪਿੱਛੇ ਹਟੋ ਅਤੇ ਦੁਬਾਰਾ ਅਜ਼ਮਾਓ।
  • 5xx — ਇੱਕ ਸਰਵਰ-ਸਾਈਡ ਗ਼ਲਤੀ; ਅਸਥਾਈ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਦੁਬਾਰਾ ਅਜ਼ਮਾਓ।

ਇੱਕ ਆਮ ਗ਼ਲਤੀ ਲਿਫ਼ਾਫ਼ਾ:

{
  "success": false,
  "error": "validation_failed",
  "message": "A human-readable explanation of the problem."
}

ਉਤਪਾਦ ਅਨੁਸਾਰ ਸਰੋਤ​

ਉੱਪਰ ਦਿੱਤੇ ਨਿਯਮ ਸਾਂਝੇ ਹਨ, ਪਰ ਹਰ ਉਤਪਾਦ ਆਪਣੇ ਖ਼ੁਦ ਦੇ ਅੰਤ-ਬਿੰਦੂ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। ਸਟੀਕ ਸਰੋਤਾਂ, ਪੈਰਾਮੀਟਰਾਂ, ਅਤੇ ਫੀਲਡ ਨਾਮਾਂ ਲਈ ਉਤਪਾਦ ਦੇ ਡਿਵੈਲਪਰ ਪੰਨੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:

  • Calendar — ਇਵੈਂਟ ਕਿਸਮਾਂ, ਉਪਲਬਧਤਾ ਸਲਾਟ, ਬੁਕਿੰਗਾਂ (ਬਣਾਓ, ਮੁੜ-ਨਿਯਤ ਕਰੋ, ਰੱਦ ਕਰੋ), ਕੈਲੰਡਰ, ਵੈੱਬਹੁੱਕ, API ਕੁੰਜੀਆਂ, ਅਤੇ ਇਵੈਂਟ ਲਿੰਕ। ਵੈੱਬਹੁੱਕ ਇਵੈਂਟ booking.created, booking.cancelled, booking.rescheduled, ਅਤੇ booking.no_show ਹਨ। ਦੇਖੋ ਡਿਵੈਲਪਰਾਂ ਲਈ Calendar।
  • Survey — ਫਾਰਮ, ਜਵਾਬ, ਜਵਾਬ ਇਕੱਤਰੀਕਰਨ, AI ਫਾਰਮ ਨਿਰਮਾਣ, ਅਤੇ ਵੈੱਬਹੁੱਕ (form.published, response.submitted)। ਦੇਖੋ ਡਿਵੈਲਪਰਾਂ ਲਈ Survey।
  • Voice Portal — ਏਜੰਟ, ਮੁਹਿੰਮਾਂ, ਅਤੇ ਸੰਪਰਕ, ਨਾਲ ਹੀ ਟੂਲ ਅਤੇ MCP ਸਰਵਰ ਰਜਿਸਟ੍ਰੇਸ਼ਨ। ਦੇਖੋ ਏਜੰਟਾਂ ਲਈ ਟੂਲ ਅਤੇ MCP।

ਸੰਬੰਧਿਤ​