Skip to content
Wetel Docs

Certified Operations (OmniChat, Nortia, aisCRM)

This content is not available in your language yet.

An action node calling one of Wetel’s certified partner products — OmniChat, Nortia, or aisCRM — doesn’t need you to know that partner’s real API by heart. Instead of hand-authoring a full request body in argsTemplate, you can pick a pre-verified operation from Wetel’s own catalog: the query/mutation text or REST request shape is already written, already checked against the partner’s live API, and kept current by Wetel as those partners’ APIs change.

Most of the catalog is GraphQL, but as of 2026-09-04 it isn’t exclusively GraphQL — a handful of Nortia operations run against a separate plain REST API (Nortia’s api-recruitment.webbyx.dev “Integration API,” distinct from its GraphQL admin API). Check an operation’s operationType ("query"/"mutation" for GraphQL, "rest_get"/"rest_post" for REST) before assuming the GraphQL-variables wiring below applies — see Wiring it into an action node.

As of this writing the catalog holds 176 certified operations across the three products — Nortia (79, including 2 REST), OmniChat (59), aisCRM (38) — covering near-complete read and write access to each partner’s real API surface, not just a handful of starter queries. That includes, for example: on OmniChat, full CRUD on contacts, conversations, tasks, teams, opportunities, labels, and automation/macro/SLA/canned-response configuration; on Nortia, candidate and job-posting lifecycle management, application/pipeline stage moves and hiring-decision recording, talent pools, calendar/interview data, company settings, usage/billing reads, candidate/interview lookups, and (the 2 REST entries) job-posting listing and résumé/candidate intake against the separate Integration API; on aisCRM, companies, contacts, deals (including pipeline/stage moves and win/loss), tasks, notes, and pipeline configuration. The catalog keeps growing — check certifiedOperations(product: ...) for the current, authoritative list rather than treating any number in this doc as final.

Not every operation in the catalog has been live-execution-verified against the partner’s API — a handful of Nortia’s newest hiring-pipeline mutations are schema-verified only, since there’s no safe, disposable test fixture to round-trip them against without touching a real candidate record. The 2 Nortia REST entries (List Job Postings (REST), Submit Resume (REST)) are now execution-verified, as of 2026-09-09: Nortia’s REST Integration API authenticates with its own static, service-owned secret (a X-Client-Secret header), separate from the bearer token used against Nortia’s GraphQL admin API — it does not carry any signed-in end user’s identity, so these two operations only work with a Wetel-provisioned shared credential (credentialSource: "NORTIA"), not a per-user SESSION_NORTIA identity. See the 2026-09-10 changelog entry. Check an operation’s own verificationNote if this distinction matters for your use case.

2026-09-09 — Nortia’s live API changed some response field names underneath 10 already-certified operations. Wetel updated the affected catalog rows’ operationDocument in place the same day, so any workflow already referencing one of these by certifiedOperationId keeps working with no re-wiring — but if your workflow reads a response field from one of these operations (e.g. in a downstream template or a RESPONSE node), check whether the field name changed: Application.current_status is now status; AgentAnswer.reply (from Ask Matchie) is now answer; Department.dept_head_name is now a relation, dept_head { id name }, on Update Department’s return value. See the changelog for the full list.

This page covers the conceptual model and the raw GraphQL/REST surface. If you’re building in the Workflow Editor UI directly, the same catalog is available as a picker on the action node’s config panel — see Action Node: Certified operations for the click-through version of everything below.

Why this exists

Section titled “Why this exists”

A Custom Action (the thing an action node calls) is a connection — an endpoint plus a credential. It has no concept of a specific GraphQL query or mutation baked into it; that text lives in the node’s own argsTemplate field, which you write from scratch every time. For a partner with a real GraphQL API, that means reading their schema, writing a query { ... } string by hand, and hoping it still matches their schema next month.

The certified catalog promotes that hand-authored knowledge into something reusable: Wetel’s own team verifies an operation against a partner’s live schema once, records exactly when, and every tenant can pick it by name from then on — no schema-reading required.

What “certified” means

Section titled “What “certified” means”
  • Wetel has read the partner’s real, current GraphQL schema and confirmed the operation actually works against a live environment.
  • Each entry carries a lastVerifiedAt date — when Wetel last confirmed it against that partner’s live schema, not just “this worked once.”
  • The catalog is Wetel-curated, not tenant-editable. You pick from it; you don’t add to it. If your use case needs an operation that isn’t certified yet, use a hand-authored argsTemplate on the same action node — certified operations are an additive alternative, not a replacement for that path.
  • Scoped to OmniChat, Nortia, and aisCRM today. WebbyX One itself isn’t a fourth product here — it’s the identity layer: signing in via WebbyX One is how you get a session-scoped credential for the other three (see Sessions API: sdkVerifyWebbyxOneIdentity), not something you query through this catalog directly.

Browsing the catalog

Section titled “Browsing the catalog”
query CertifiedOperationsForOmnichat {
  certifiedOperations(product: "OMNICHAT") {
    id
    label
    description
    operationType
    isDeprecated
    compatibleCredentialSources
    lastVerifiedAt
  }
}

product is one of "OMNICHAT", "NORTIA", or "AISCRM" (a plain string, not an enum on the wire). The list includes deprecated entries too (check isDeprecated) — a workflow already referencing one keeps resolving it; you just shouldn’t pick a deprecated one for new work if a newer entry covers the same need.

compatibleCredentialSources tells you which Custom Action credentialSource values this operation is meant to pair with — for example ["OMNICHAT", "SESSION_OMNICHAT"], meaning it works whether the action authenticates with a tenant-wide shared OmniChat account or a signed-in end user’s own linked session identity. This must match the action node’s own customActionId — see wiring it into a node below.

What’s realistically self-serve today: createCustomAction doesn’t expose a way to create an OMNICHAT, NORTIA, or AISCRM (tenant-wide shared account) custom action directly — those are Wetel-provisioned. For OmniChat, aisCRM, and Nortia alike, the practical self-serve path is SESSION_OMNICHAT/SESSION_AISCRM/SESSION_NORTIA: create a custom action with credentialSource set to that value (no bearerToken needed), have your end users sign in via WebbyX One and link their own product identity (see Sessions API: sdkVerifyWebbyxOneIdentity), then reference that action’s id. See Credential sources for the full table.

Fetch one operation’s full detail — including the real, verified query/mutation text — once you’ve chosen one:

query CertifiedOperationDetail {
  certifiedOperation(id: 12) {
    id
    label
    description
    operationType
    operationDocument
    variablesSchema
    isDeprecated
    verificationNote
  }
}

For a GraphQL operation (operationType "query"/"mutation"), operationDocument is the real GraphQL text Wetel verified. For a REST operation (operationType "rest_get"/"rest_post"), operationDocument is a human-readable METHOD /path description instead — documentation, not something the node sends — since a REST call has no query text to wrap; see Wiring it into an action node. Either way, variablesSchema is documentation only in v1 (not runtime-enforced) — it describes the shape of the values this operation expects, so you know what to put in argsTemplate without guessing.

Both queries accept either JWT dashboard authentication or an X-Api-Key header — whichever you send, plus the x-huat-platform: customer header, same as every other operation in this section. This makes the catalog browsable from a pure server-to-server integration that only ever holds an API key, not a signed-in user’s JWT — see API Reference Overview for the two auth tiers.

Wiring it into an action node

Section titled “Wiring it into an action node”

Set certifiedOperationId on the node’s config alongside the customActionId it should pair with. What argsTemplate means once you do this depends on the operation’s operationType:

  • GraphQL ("query"/"mutation") — argsTemplate is no longer the full request body, it’s this operation’s GraphQL variables. The node sends { "query": "<the certified operationDocument>", "variables": <your rendered argsTemplate> } to the action’s endpoint — you never write the query text yourself, only the variables (if the operation takes any).
  • REST ("rest_get"/"rest_post") — argsTemplate is unchanged: it’s still the full request body/params, exactly as if you’d hand-authored the call yourself. There’s no wrapper — certifiedOperationId here is purely a discoverability/documentation aid (the real target endpoint still comes from the paired Custom Action’s own url/method), not a query-text substitution.
{
  "id": "list_omnichat_contacts",
  "type": "action",
  "label": "List OmniChat Contacts",
  "config": {
    "customActionId": 9,
    "certifiedOperationId": 12,
    "argsTemplate": "{}",
    "outputVar": "contacts_result",
    "timeoutMs": 8000
  },
  "position": { "x": 250, "y": 220 }
}

The example above is GraphQL (operationType: "query") — takes no variables, hence "{}". A REST example, Nortia’s Submit Resume (REST) (operationType: "rest_post"), looks like an ordinary hand-authored action node — argsTemplate carries the real request fields directly, including a file_base64 value produced by a preceding fetchAsBase64Var node:

{
  "id": "submit_resume_to_nortia",
  "type": "action",
  "label": "Submit Résumé to Nortia",
  "config": {
    "customActionId": 21,
    "certifiedOperationId": 174,
    "argsTemplate": "{\"company_id\": 41, \"job_posting_id\": {{jobPostingId}}, \"file_name\": \"resume.pdf\", \"file_base64\": \"{{resumeBase64}}\", \"source\": \"omnichat\"}",
    "outputVar": "submit_resume_result"
  },
  "position": { "x": 450, "y": 220 }
}

The certified operation’s compatibleCredentialSources must include the action’s own credentialSource, or the node fails at execution time with a clear, node-scoped error naming both values — this is re-validated on every run, not just when you save the node, the same way this platform validates every other cross-reference. Picking a Nortia-only certified operation on an action configured with an OmniChat credential is the kind of mistake this check exists to catch loudly instead of silently misbehaving.

Requesting a new certified operation

Section titled “Requesting a new certified operation”

Need an operation that isn’t in the catalog yet — a query or mutation your workflow depends on that Wetel hasn’t hand-verified for OmniChat, Nortia, or aisCRM? Reach out to the Wetel team with the partner, the operation you need, and what it should return, and we’ll verify it against that partner’s live API and add it to the catalog. In the meantime, a hand-authored argsTemplate on the same action node works today and isn’t blocked on this — the certified catalog is an additive convenience, not a gate.

Next steps

Section titled “Next steps”