Nintex eSign integration

Nintex automates workflows inside SharePoint, Microsoft 365, and Salesforce. Teams search "Nintex eSign" when they want approval routes that end in a signed PDF without custom code for every branch.

Atlas does not ship a Nintex marketplace connector today. You integrate through HTTP actions, webhooks, and the REST API.

Architecture pattern

Nintex workflow (start)
  → HTTP action: POST /api/envelope
  → Parse review_url into workflow variable
  → Optional human task: open review, click Send
  → Or template send with auto_send for trusted docs
  → Atlas webhook → Nintex HTTP callback
  → Update SharePoint item / Salesforce field

Keep signing logic in Atlas. Use Nintex for routing, approvals, and list updates.

Step 1: Create envelope from Nintex

Configure an HTTP action in Nintex Workflow Cloud or on-prem (depending on your edition):

URL: https://atlaswork.ai/api/envelope

Method: POST

Headers:

Authorization: Bearer {{atlas_api_key}}
Content-Type: application/json
Idempotency-Key: {{workflowInstanceId}}-create

Body example:

{
  "document_url": "{{SharePointFileUrl}}",
  "parties": [
    {
      "email": "{{InitiatorEmail}}",
      "name": "{{InitiatorDisplayName}}",
      "role": "Employee"
    }
  ],
  "webhook_url": "https://your-middleware.example/nintex/atlas"
}

Parse envelope_id and review_url from the JSON response into workflow variables.

Step 2: Review gate vs auto-send

Ad-hoc documents: Assign a human task with the review_url. Approver confirms fields, then call send:

POST https://atlaswork.ai/api/envelope/{{envelope_id}}/send

Trusted templates: Skip upload. Call template send directly:

POST https://atlaswork.ai/api/templates/{{template_id}}/send

Set "auto_send": true in the body when legal already approved the template.

This mirrors the Atlas trust ladder: review first, automation second.

Step 3: Webhook back into Nintex

Atlas POSTs signed events to your webhook_url. Verify X-Atlas-Signature with HMAC-SHA256 using your API key.

Your middleware (Azure Function, small Node service) translates payloads into something Nintex accepts:

• Update a SharePoint column SignedDate
• Attach signed PDF URL to list item
• Call Nintex webhook start URL to resume a paused workflow

Nintex cannot verify Atlas HMAC natively in all editions. Use a thin middleware layer.

Step 4: Status polling fallback

If webhooks are blocked on-prem, poll:

GET https://atlaswork.ai/api/envelope/{{envelope_id}}/status

Schedule a Nintex timer loop until status is signed, declined, or voided. Webhooks are preferred to avoid poll spam.

SharePoint file URLs

document_url must be reachable by Atlas servers. Expiring SharePoint tokens break create. Patterns that work:

• SAS URL with sufficient TTL
• Public CDN copy for non-sensitive drafts
• Base64 upload via middleware that reads SharePoint with app permissions

DOCX and PDF both work on create.

Error handling

Store metadata.send_error from Atlas responses in your run log for support.

Security

• Store API keys in Nintex connections or Azure Key Vault, not plain text in workflow definitions
• Rotate keys when admins leave
• Use Idempotency-Key on create/send to survive Nintex retries

Comparison to native Nintex DocuSign actions

Nintex offers DocuSign connectors in some bundles. Teams still evaluate Atlas when:

• Agents or external APIs must create envelopes outside Nintex
• Usage-based pricing beats DocuSign seats for low-volume branches
• MCP signing from Claude should feed the same envelope store

DocuSign remains fine when Nintex + DocuSign is already licensed enterprise-wide.

On-premises Nintex notes

On-prem Nintex Workflow may block outbound HTTPS to unknown hosts. Allowlist atlaswork.ai on your proxy. Some teams deploy middleware in Azure VNet with fixed egress IP and register that IP if Atlas IP allowlisting is enabled on your account.

Document the outbound path before go-live. Silent proxy blocks look like mysterious workflow hangs.

Testing checklist

1. Create test envelope from Nintex with sandbox API key
2. Complete sign flow on mobile (events are phone-heavy)
3. Verify webhook hits middleware and SharePoint column updates
4. Void test envelope and confirm credit behavior
5. Promote template to production key

Variable naming in Nintex

Use explicit workflow variables:

Clear names prevent sending the wrong ID into a later HTTP action after branching.

Dual-vendor period

During DocuSign-to-Atlas migration, Nintex branches can route by document type: legacy templates call DocuSign connector, new templates call Atlas HTTP actions. Run both until signed PDF retention parity is verified, then retire the DocuSign branch.

Logging for support

Log envelope_id, Nintex instance ID, and HTTP status from every Atlas call. When support asks about a stuck workflow, those three fields pinpoint the failure without replaying production PDFs locally.

Related

• E-signature API
• HubSpot document signing (similar middleware pattern)
• Webhooks and debugging
• DocuSign Envelope API migration map