Integrations

Connect GrowerIQ to external systems like SAP, QuickBooks, Shopify, and custom ERP platforms.

By Customer Success Team

• 7 articles

Integrations Overview

GrowerIQ connects to external systems through integrations, allowing you to synchronise inventory, orders, invoices, and more with the tools your organisation already uses. Two types of integrations are available: pre-built integrations managed by the GrowerIQ team, and custom API integrations you provision and control yourself. In this article - Pre-Built Integrations - Custom API Integrations - Security at a Glance - In This Section Pre-Built Integrations Pre-built integrations are managed connections where the GrowerIQ team handles setup and configuration on your behalf. These integrations do not appear in the custom integration vendor dropdown. !!! info "Managed by GrowerIQ" Pre-built integrations are configured by the GrowerIQ team after you submit a setup request. You do not need to manage API credentials or webhooks for these connections. WooCommerce Automatic SKU and order synchronisation between GrowerIQ and your WooCommerce store. Product data is pushed to WooCommerce, and incoming orders are received back into GrowerIQ. Shopify Automatic SKU and order synchronisation between GrowerIQ and your Shopify store. Product data is pushed to Shopify, and incoming orders are received back into GrowerIQ. QuickBooks Online Automatic push of CRM account records and invoices from GrowerIQ to QuickBooks Online, keeping your accounting system up to date without manual data entry. How to request a pre-built integration 1. Navigate to Administration > Integrations. 2. Click Set Up an Integration. 3. Fill out the integration request form with your connection details. 4. The GrowerIQ team will handle the rest of the configuration. !!! tip "Quick turnaround" Most pre-built integrations are configured within one business day of receiving your request. Custom API Integrations For ERP systems (SAP, Dynamics, NetSuite) or any custom system, use custom API integrations. These are self-service connections you provision directly through the admin UI. Each custom integration receives its own set of API credentials with configurable permissions (scopes), so you control exactly what each external system can access. Outbound webhooks notify your external systems in real time when events occur in GrowerIQ. Custom API integrations are built with SOC 2 compliance controls, including audit logging, credential hashing, and request tracing. !!! info "API Reference Portal" For API endpoint reference, authentication code samples, and payload schemas, refer to the GrowerIQ API Reference portal. Contact your Customer Success representative for access. Integration list page showing vendor cards with status filters Security at a Glance All integrations (both pre-built and custom) benefit from GrowerIQ's security controls: - Dual-layer authentication using JWT token and API key - Per-integration scopes following the principle of least privilege - API keys stored as one-way hashes (never stored in plain text) - All API calls logged with full request tracing - Webhook payloads signed with HMAC-SHA256 - Optional IP allowlisting and configurable rate limits !!! warning "Protect your API keys" API keys are shown only once at creation time. Store them securely in a secrets manager or password vault. If a key is lost or compromised, revoke it immediately and generate a new one. In This Section Explore each topic in detail: 1. Creating and Managing Integrations 2. Managing API Credentials 3. Setting Up Webhooks 4. Webhook Security and Troubleshooting 5. Viewing API Logs 6. Integration Security Controls

Last updated on Apr 01, 2026

Creating and Managing Integrations

GrowerIQ uses a structured provisioning workflow for custom API integrations. Every integration passes through a defined lifecycle, from initial request through approval, activation, and (if necessary) suspension or revocation. This workflow ensures SOC 2 compliance with separation of duties; the person who requests an integration cannot be the same person who approves it. In This Article - Prerequisites - Requesting an Integration - Selecting Scopes - Approval Workflow - Activating an Integration - Updating an Integration - Suspending an Integration - Reactivating an Integration - Revoking an Integration - Lifecycle Summary - Tips and Best Practices - Troubleshooting Prerequisites Before you begin, confirm the following: - Your account has the administration_integrations_access permission. - Your organisation has at least two admin users. The dual-approval requirement means a different administrator must approve each integration request. Requesting an Integration 1. Navigate to Administration > Integrations. 2. Click Create Integration. 3. Select a vendor from the registry table. The following vendors are available: | Vendor | Category | |---|---| | SAP | ERP, procurement | | Salesforce | CRM sync | | QuickBooks Online | Accounting | | Xero | Accounting | | Shopify | Ecommerce | | HubSpot | Marketing | | NetSuite | ERP | | Sage | Accounting | | Zapier | Workflow automation | | Microsoft Dynamics 365 | ERP | | Power Automate | Workflow automation | | Custom | Any other system | 4. Enter a Name and Description for the integration. 5. Assign an Owner (the person responsible for this integration going forward). 6. Click Submit. The integration is now created in Requested status. It cannot access any data until it has been approved and activated. Selecting Scopes During creation (or when updating an existing integration), select the scopes that define what the integration can access. Only grant scopes that the integration actually needs. | Category | Read | Write | What It Grants | |---|---|---|---| | Inventory | Yes | Yes | Lots, batches, plants, rooms, locations | | Consumables | Yes | Yes | Consumable lots and classes | | Orders | Yes | Yes | Orders, order items, shipments, manifests | | SKUs | Yes | Yes | SKU definitions and price tables | | Equipment | Yes | Yes | Equipment records: sensors, controllers, actuators, monitors. Supports external IDs. | | Sensors | -- | Yes | Batch-ingest sensor readings, up to 500 per request with partial success | | Taxonomies | Yes | -- | Varieties, categories, equipment types (read-only) | | Compliance | Yes | Submit | CAPAs, deviations, recalls | | Reports | Yes | Execute | Generate and download reports | | Quality | Yes | -- | SOPs, colour grades, quality data (read-only) | | Finance | Yes | -- | Transactions, invoices, taxes (read-only) | | CRM | Yes | Yes | Accounts and contacts (contains PII) | | Tasks | Yes | Yes | Tasks, comments, assignments | | Activities | Yes | -- | Activity log entries (read-only) | | Webhooks | -- | Manage | Manage webhook subscriptions | !!! warning "PII and Financial Data" The CRM scope grants access to personally identifiable information (PII), including contact names, emails, and phone numbers. The Finance scope exposes transaction and invoice data. Grant these scopes only when the integration has a legitimate business need, and review them during quarterly audits. !!! tip "IoT and Sensor Integrations" For IoT or environmental monitoring systems, enable both the Equipment and Sensors scopes. The Sensors write scope supports batch ingestion of up to 500 readings per request with partial success. If some readings fail validation, the valid ones are still persisted and the response indicates which entries were rejected. Approval Workflow !!! info "Dual-Approval Requirement (SOC 2)" A different administrator must approve the integration. The user who submitted the request cannot approve their own integration. This separation of duties is enforced by the system and satisfies SOC 2 audit requirements. 1. A second administrator navigates to Administration > Integrations. 2. Open the integration in Requested status. 3. Review the selected scopes, owner, and description. 4. Click Approve. The integration moves to Approved status. It is now ready to be activated. Activating an Integration 1. Open the approved integration. 2. Click Activate. 3. The system generates API credentials (client ID and client secret) and displays them on screen. !!! danger "Save Your Credentials Immediately" The API credentials are shown only once. After you close the dialog, the secret is stored as a one-way hash and cannot be retrieved. Copy the credentials to a secure vault (such as your secrets manager) before closing the window. If you lose the credentials, you must suspend and reactivate the integration to generate new ones. Integration detail page showing status, scopes, API key prefix, and lifecycle actions The integration is now Active and can make API calls within the granted scopes. Updating an Integration You can modify an active integration without suspending it: - Scopes: Add or remove scopes as business needs change. - Rate limits: Adjust the requests-per-minute or daily quota. - Owner: Reassign the integration to a different team member. Navigate to the integration detail page, make your changes, and click Save. Scope changes take effect on the next API call. Suspending an Integration Suspend an integration when you need to temporarily disable access without permanently revoking it. Common reasons include: - A security concern that requires investigation. - A partner offboarding or contract pause. - Unexpected API behaviour that needs review. To suspend: 1. Open the integration. 2. Click Suspend. 3. Enter a reason for the suspension (required for audit trail). 4. Confirm. The integration's API key is invalidated immediately. All configuration, scopes, and history are preserved. Any in-flight API calls will receive a 401 Unauthorized response. Reactivating an Integration !!! info "Dual-Approval Required" Reactivation requires a different administrator than the one who suspended the integration. This maintains the separation-of-duties control throughout the lifecycle. 1. A different administrator opens the suspended integration. 2. Click Reactivate. 3. New API credentials are generated and displayed on screen. Save the new credentials immediately (the previous credentials are permanently invalidated). The integration returns to Active status. Revoking an Integration Revocation is permanent and terminal. Use it when an integration is no longer needed. 1. Open the integration. 2. Click Revoke. 3. Confirm the action. The integration moves to Revoked status. Its API key is invalidated, and the integration cannot be reactivated. If you need the same integration in the future, create a new one from scratch. Lifecycle Summary Every integration follows this state machine: Requested ──> Approved ──> Active <──> Suspended │ │ │ │ └─────────────┴───────────┴─────────────┘ │ v Revoked (terminal) - Requested: Awaiting approval from a second administrator. - Approved: Approved but not yet activated (no credentials issued). - Active: Credentials issued, integration can make API calls. - Suspended: Temporarily disabled, credentials invalidated, configuration preserved. - Revoked: Permanently disabled, cannot be restored. Tips and Best Practices - Maximum integrations: Each organisation can have up to 20 active integrations at a time. Plan accordingly. - Use descriptive names: Name integrations clearly (for example, "SAP Procurement Sync" rather than "SAP"). This helps during quarterly reviews. - Review quarterly: Audit active integrations every quarter. Revoke any that are no longer in use. - Document the business purpose: Use the description field to record why the integration exists and which business process it supports. This context is invaluable during audits and team transitions. - Principle of least privilege: Grant only the scopes the integration actually needs. You can always add more later. Troubleshooting "I can't approve my own integration." This is by design. The dual-approval workflow requires a different administrator to approve each request. Ask a colleague with admin access to review and approve it. "My integration is stuck in Requested status." A different administrator needs to approve it. Check that your organisation has at least two users with the administration_integrations_access permission. "I hit the 20-integration limit." Revoke integrations that are no longer in use. Suspended integrations also count toward the limit, so revoke (rather than suspend) integrations you will not need again.

Last updated on Apr 01, 2026

Managing API Credentials

Every GrowerIQ integration uses two credentials that work together: an API key that identifies the integration, and a JWT token that proves the caller is authorised. This dual-layer model ensures that compromising one credential alone is not enough to access your data. In this article - How Authentication Works - What to Share with Your Integration Partner - API Key Security Model - Regenerating an API Key - Auth0 Client Credentials - Troubleshooting Partner Authentication Errors How Authentication Works Every API request to GrowerIQ must include both credentials. Each serves a distinct purpose: | Credential | HTTP Header | Purpose | Lifetime | |---|---|---|---| | JWT Token | Authorization: Bearer <token> | Proves the caller is authorised | 1 hour (must be refreshed) | | API Key | X-API-Key: <key> | Identifies which integration is calling | Until regenerated or revoked | The JWT token is short-lived and must be refreshed before it expires. The API key persists indefinitely until you explicitly regenerate or revoke it. Both must be present on every request, or the call is rejected. !!! info "Why two credentials?" A stolen API key alone cannot make API calls because it lacks a valid JWT. A stolen JWT alone cannot make calls because it lacks the API key. An attacker would need to compromise both simultaneously. What to Share with Your Integration Partner When onboarding a new integration partner, share the following credentials so they can authenticate against your GrowerIQ environment: | Credential | Share? | Handling | |---|---|---| | API Key | Yes | Via secrets manager or password vault | | Auth0 Client ID | Yes | Secure handoff | | Auth0 Client Secret | Yes | Secure handoff | | Auth0 Domain | Yes | Can share openly | | API Docs URL | Yes | Can share openly | | Granted Scopes | Yes | Can share openly | | Webhook Signing Secret | Yes (if using webhooks) | Secure handoff | !!! warning "Never share credentials via email or chat" Always use a secrets manager, password vault, or other encrypted channel to transfer API keys, client secrets, and webhook signing secrets. Plain-text email and chat messages are logged, cached, and searchable by unintended recipients. API Key Security Model GrowerIQ API keys follow a secure-by-design approach: - Format: Keys begin with grq_live_ followed by a cryptographically random string. - Displayed once: The full key is shown only at activation or regeneration. Copy it immediately. - Stored as a hash: GrowerIQ stores only a one-way hash of the key. Support staff cannot retrieve it for you. - Prefix visible in UI: The integration detail page shows only the first 16 characters (the prefix) for identification purposes. - Lost key recovery: If you lose the key, the only option is to regenerate it. The old key stops working immediately. !!! info "Treat your API key like a password" Store the full key in a secrets manager the moment it is displayed. You will not be able to view it again. Integration detail showing the API key prefix and scope badges Regenerating an API Key Regenerate an API key when you suspect it has been compromised, when staff with access to the key leave the organisation, or as part of routine credential rotation. Steps: 1. Navigate to Administration > Integrations and select the integration. 2. On the integration detail page, click Regenerate API Key. 3. Copy the new key immediately and store it in your secrets manager. 4. Provide the new key to your integration partner through a secure channel. !!! danger "Regeneration takes effect immediately" The moment you regenerate, the old API key stops working. Any system still using the old key will receive authentication errors. Coordinate the key swap with your integration partner before regenerating to avoid downtime. Auth0 Client Credentials The GrowerIQ Customer Success team sets up an Auth0 application for each integration during onboarding. Your integration partner uses the Auth0 client credentials to obtain JWT tokens. The authentication flow works as follows: 1. The partner calls the Auth0 token endpoint with their client_id and client_secret. 2. Auth0 returns a JWT token valid for 1 hour. 3. The partner includes both the JWT token (Authorization: Bearer) and the API key (X-API-Key) on every API call. 4. When the JWT expires, the partner requests a new one from Auth0. The API key remains the same. !!! info "Auth0 credentials are set up for you" You do not need to create the Auth0 application yourself. The GrowerIQ team configures it during integration onboarding and provides the credentials via secure handoff. Troubleshooting Partner Authentication Errors If your integration partner reports authentication failures, work through this checklist: !!! tip "Common causes of authentication errors" - Integration is not Active. Verify the integration status is set to Active on the detail page. - API key was regenerated. Confirm the partner is using the current API key, not a previously issued one. - JWT token has expired. JWT tokens are valid for 1 hour. Ensure the partner's system refreshes the token before expiry. - Missing credential on the request. Both the Authorization: Bearer header (JWT) and the X-API-Key header (API key) must be present on every call. A missing header results in a 401 Unauthorised response. If all four checks pass and the issue persists, review the API Logs page for the integration to see the exact error returned on each request.

Last updated on Apr 01, 2026

Setting Up Webhooks

Webhooks let GrowerIQ notify external systems when something happens, such as a lot being created, an order shipped, or a harvest recorded. Instead of polling the API on a schedule, GrowerIQ pushes event data to a URL you specify the moment an event occurs. In this article - How Webhooks Work - Creating a Webhook Subscription - Choosing Activity Types - Testing Your Webhook - Managing the Signing Secret - Editing and Deleting Webhooks How Webhooks Work When an event occurs in GrowerIQ, the system follows this sequence: 1. An event occurs (for example, a lot is created or a shipment is marked as delivered). 2. GrowerIQ checks for webhook subscriptions that match the event's activity type. 3. For each matching subscription, GrowerIQ sends an HTTP POST request to the configured endpoint URL. 4. The payload is signed with HMAC-SHA256 using the subscription's signing secret so your receiver can verify authenticity. 5. The delivery attempt and response are recorded in the delivery log. !!! info "Organisation-wide subscriptions" Webhooks are configured at the organisation level, not per-integration. A single webhook subscription receives events from all integrations and internal operations that match the selected activity types. Creating a Webhook Subscription Follow these steps to create a new webhook subscription: 1. Navigate to Administration > Webhooks. 2. Click Create Webhook. 3. Enter the Endpoint URL for the system that will receive events. The URL must use HTTPS. 4. Select one or more Activity Types that should trigger a delivery to this endpoint. 5. Click Create. After creation, GrowerIQ displays the signing secret for this subscription. !!! danger "Save your signing secret immediately" The signing secret is displayed only once at creation time. Copy it and store it in a secrets manager or password vault before closing the dialog. You cannot retrieve this secret later. If it is lost, you must regenerate it (which invalidates the previous secret). Webhook subscriptions page showing active and paused webhook cards Choosing Activity Types Activity types determine which events trigger a webhook delivery. Select only the types your receiver needs. | Category | Activity Types | |---|---| | Cultivation | Batch created, harvest recorded, drying complete, curing complete | | Inventory | Lot created, lot transferred, weight adjusted, destruction queued, destruction completed | | Orders & Shipments | Order created, order status changed, shipment shipped, shipment delivered | | Quality & Compliance | Sample created, lab results received, CAPA opened, deviation recorded, recall initiated | | Plant Care | Pesticide applied, fertiliser applied, cuttings propagated, seeds germinated | | Production | Crude extraction recorded, distillation recorded, final product weights recorded | !!! tip "Start narrow, expand later" Subscribe to only the activity types your integration needs right now. You can add more types at any time by editing the subscription. Fewer subscriptions means less noise and easier debugging. Testing Your Webhook Before relying on a webhook in production, verify that your endpoint receives and processes payloads correctly. 1. Open the webhook subscription detail page by clicking on the subscription in Administration > Webhooks. 2. Click Test Webhook. GrowerIQ sends a sample payload to your endpoint. 3. Check the Delivery Log on the subscription detail page. A successful delivery shows a 2xx status code. A failed delivery shows the HTTP status or error returned by your endpoint. !!! tip "Use webhook.site for initial testing" If you do not have a receiver ready, create a temporary endpoint at webhook.site and use that URL when creating the subscription. This lets you inspect the exact payload structure and headers GrowerIQ sends before you write any receiver code. Managing the Signing Secret The signing secret is a shared key used to compute the HMAC-SHA256 signature included in every webhook delivery. Your receiver uses this secret to verify that payloads genuinely come from GrowerIQ and have not been tampered with. Regenerating the secret If the signing secret is lost or compromised: 1. Update your receiver first. Prepare your receiver to accept a new secret so there is no gap in verification. 2. Navigate to the webhook subscription detail page. 3. Click Regenerate Secret. 4. Copy and store the new secret immediately. 5. Deploy the new secret to your receiver. !!! warning "Regeneration invalidates the previous secret" As soon as you regenerate, the old secret stops working. Any deliveries signed with the old secret will fail verification on your receiver. Update your receiver before or immediately after regenerating to avoid missed events. Editing and Deleting Webhooks Editing a subscription To change the endpoint URL or update the selected activity types: 1. Navigate to Administration > Webhooks. 2. Click on the subscription you want to modify. 3. Update the Endpoint URL or toggle Activity Types as needed. 4. Click Save. Changes take effect immediately for all subsequent events. Deleting a subscription To remove a webhook subscription: 1. Navigate to Administration > Webhooks. 2. Click on the subscription you want to remove. 3. Click Delete. 4. Confirm the deletion. Deleting a subscription cancels any pending deliveries and stops all future deliveries for that endpoint. This action cannot be undone.

Last updated on Apr 01, 2026

Viewing API Logs

Every API call made by an integration is automatically logged by GrowerIQ. The log viewer provides full visibility into what your integrations are doing, making it straightforward to troubleshoot issues, verify activity, and produce evidence for compliance audits. In this article - Accessing the Log Viewer - Understanding Log Entries - Filtering Logs - Common Use Cases Accessing the Log Viewer Navigate to QA > Integration API Logs to open the log viewer. The page displays a table of all API requests made by integrations, sorted by most recent first. !!! info "Permissions required" Only users with QA or Administrator roles can access the Integration API Logs page. Integration API Logs grid showing timestamps, integrations, methods, endpoints, and status codes Understanding Log Entries Each row in the log table represents a single API request. The following columns are displayed: | Column | Description | |--------|-------------| | Timestamp | Date and time the request was made | | Integration | Which integration made the call | | Method | HTTP method used (GET, POST, PATCH) | | Endpoint | API path that was called (e.g., /lots, /orders/123) | | Status | HTTP response code: 200 = success, 4xx = client error, 5xx = server error | | Duration | Time to process the request, in milliseconds | | IP Address | Origin IP address of the request | | Request ID | Unique identifier for this specific request | | Error | Error code if the request failed (e.g., insufficient_scope, rate_limit_exceeded) | Filtering Logs Use the filter controls at the top of the log viewer to narrow results: - Integration -- select a specific integration to view only its requests. - Date Range -- set a start and end date to view logs within a specific window. - Status -- filter by success or error to isolate failed requests. - Endpoint -- search for a specific API path to see all calls to that resource. Combine multiple filters to quickly locate the entries you need. For example, filter by a specific integration and error status to see only its failed requests over the past week. Common Use Cases Troubleshooting with a partner When working with an integration partner to resolve an issue, locate the failed request in the log viewer and share the Request ID. This allows both sides to reference the exact same request without ambiguity. !!! tip "Finding the Request ID" The Request ID also appears in the X-Request-ID response header returned by the API. Share this value with GrowerIQ support or your integration partner for faster resolution. Verifying integration health Check that an integration is actively making calls and receiving successful responses. A healthy integration shows recent timestamps with predominantly 200-series status codes. Detecting rate limit issues Filter by Status for 429 response codes. If an integration is hitting rate limits, you will see clusters of 429 entries. Consider adjusting the integration's request frequency or contact GrowerIQ support to discuss rate limit increases. Compliance audits For SOC 2 and other compliance frameworks, the log viewer provides evidence of access controls in action. Export the page or take screenshots to document which integrations accessed which endpoints and when. Auditors can verify that integrations operated within their assigned scopes. Security investigation If an integration's credentials are suspected of being compromised, use the log viewer to review which endpoints were accessed, from which IP addresses, and at what times. This information helps assess the scope of any unauthorized access before revoking the credentials.

Last updated on Apr 01, 2026

Webhook Security and Troubleshooting

GrowerIQ signs every outbound webhook payload with HMAC-SHA256 so your receiving system can verify the request genuinely originated from GrowerIQ and has not been tampered with in transit. In this article - Signature Verification - Replay Protection - Retry Behaviour - Reading Delivery Logs - Health Status - Troubleshooting Signature Verification Every webhook request includes two headers used for verification: | Header | Value | Purpose | |--------|-------|---------| | X-Webhook-Signature | sha256=<hex-digest> | HMAC-SHA256 signature of the payload | | X-Webhook-Timestamp | Unix timestamp (seconds) | Time the payload was signed | Follow these steps to verify a webhook signature: 1. Extract the X-Webhook-Timestamp header value. 2. Reject the request if the timestamp is older than 5 minutes (see Replay Protection below). 3. Build the signed string by concatenating: <timestamp>.<raw-request-body> (dot separator between timestamp and body). 4. Compute an HMAC-SHA256 digest of the signed string using your webhook signing secret as the key. 5. Compare the computed digest against the value in the X-Webhook-Signature header (after stripping the sha256= prefix). Use a timing-safe comparison function to prevent timing attacks. !!! info "Code Samples" For language-specific verification examples (Python, Node.js, Ruby, and more), refer to the GrowerIQ API Reference portal. Contact your Customer Success representative for access. Replay Protection Your receiving system should reject any webhook payload where the X-Webhook-Timestamp value is older than 5 minutes relative to your server's current time. This prevents replay attacks, where an attacker intercepts a valid payload and re-sends it later. !!! warning "Clock Synchronisation" Ensure your receiving server's clock is synchronised with NTP. Clock skew greater than a few seconds can cause valid webhooks to be incorrectly rejected. Retry Behaviour If your endpoint returns a 5xx status code or the connection times out, GrowerIQ retries delivery on an escalating schedule: | Attempt | Timing | |---------|--------| | 1 | Immediate | | 2 | 1 minute later | | 3 | 5 minutes later | | 4 | 30 minutes later | | 5 | 2 hours later (final) | !!! warning "4xx Errors Are Never Retried" A 4xx response indicates a configuration problem on the receiver side (wrong URL, missing authentication, malformed endpoint). GrowerIQ does not retry these. Check your endpoint configuration and correct the issue. !!! info "Idempotency" Because retries can deliver the same payload more than once, design your receiving endpoint to be idempotent. Use the event ID in the payload to detect and discard duplicates. Reading Delivery Logs Use delivery logs to confirm whether a webhook was received, identify error codes, and track retry attempts. 1. Navigate to Administration > Integrations. 2. Open the integration that owns the webhook subscription. 3. Click the webhook subscription to view its detail page. 4. Select the Delivery Logs tab. Each row in the log displays: - Timestamp of the delivery attempt - HTTP status code returned by your endpoint - Attempt number (1 through 5) - Error details if the request failed (timeout, connection refused, etc.) Use these logs to confirm successful delivery, identify which status codes your endpoint is returning, and track how many retry attempts have been made. Webhook detail page showing endpoint URL, activity types, and delivery logs tab Health Status After all 5 delivery attempts fail for a webhook event, GrowerIQ marks the subscription status as Failing. While in this state, new events continue to queue but may experience delayed delivery. To recover a failing subscription: 1. Fix the underlying issue with your receiving endpoint. 2. Navigate to the webhook subscription detail page. 3. Click Send Test Webhook to verify connectivity. 4. Once a test webhook succeeds, the subscription returns to Active status and queued events resume delivery. Troubleshooting Webhook not firing - Confirm the webhook subscription is in Active status. - Verify the correct activity type is selected in the subscription's event filter. - Confirm the triggering event actually occurred (check the activity log for the relevant record). - Allow up to 10 seconds for delivery. Webhooks are dispatched asynchronously after the triggering event. Getting 4xx errors - Double-check the endpoint URL for typos or incorrect paths. - If your endpoint requires authentication, note that GrowerIQ sends a User-Agent: GrowerIQ-Webhook/1.0 header but does not include authorization headers. Configure your endpoint to accept unauthenticated requests from GrowerIQ, or use signature verification as your authentication mechanism. - Check whether the payload size exceeds your endpoint's request body limit. Signature mismatch - Verify you are using the correct signing secret (found on the webhook subscription detail page). - Compute the HMAC over the raw request body bytes, not a re-serialised or re-parsed string. Whitespace or key-ordering changes will break the signature. - Confirm the signed string format is <timestamp>.<body> with a literal dot (.) separator between the timestamp and body. - Check for clock skew between your server and GrowerIQ. Large clock drift can cause timestamp-related verification failures. Events arriving late - Normal delivery latency is approximately 10 seconds after the triggering event. - Under heavy system load, events may queue briefly before dispatch. - Check the Delivery Logs tab to see if earlier failed attempts and retries are consuming the delivery queue ahead of newer events.

Last updated on Apr 01, 2026

Integration Security Controls

GrowerIQ provides layered security controls for every integration. Apply the principle of least privilege: grant only the access an integration needs, restrict where it can connect from, and limit how often it can call the API. In this article - Scopes: What Can an Integration Access? - Rate Limits - IP Allowlisting - Responding to a Security Incident - Quarterly Review Checklist Scopes: What Can an Integration Access? Scopes define which areas of GrowerIQ an integration is allowed to read or write. Assign scopes when creating the integration and adjust them at any time. | Category | What It Covers | Sensitivity | |---|---|---| | Inventory | Lots, batches, plants, rooms, locations, transfers, destruction | Operational | | Consumables | Consumable lots and classes | Operational | | Orders | Orders, shipments, manifests | Operational | | SKUs | Product definitions, price tables | Operational | | Equipment | Equipment records: sensors, controllers, actuators, monitors | Operational | | Sensors | Batch-ingest sensor readings: temperature, humidity, CO2 | Operational | | Taxonomies | Varieties, categories, equipment types | Operational (read-only) | | Compliance | CAPAs, deviations, recalls, compliance reports | Regulatory | | Reports | Generate and download reports | Operational | | Quality | SOPs, colour grades, quality data | Operational (read-only) | | Finance | Transactions, invoices, taxes | Financial | | CRM | Customer accounts and contacts | PII | | Tasks | Tasks, comments, assignments | Operational | | Activities | Activity log entries | Operational (read-only) | | Webhooks | Webhook subscription management | Administrative | !!! warning "Principle of least privilege" Fewer scopes means a smaller blast radius if credentials are compromised. Grant only the scopes your integration actively uses. An ERP sync that reads inventory and orders does not need access to CRM or Finance. Scope changes on active integrations take effect immediately and are recorded in the audit log. Removing a scope from a live integration causes any subsequent API calls requiring that scope to return 403 Forbidden. Rate Limits Rate limits protect GrowerIQ from runaway integrations and ensure fair resource sharing across all connected systems. - Default limit: 60 requests per minute (RPM) - Configurable range: 1 to 10,000 RPM - Enforcement: When an integration exceeds its limit, the API returns 429 Too Many Requests until the window resets. Every API response includes rate-limit headers so your integration can self-throttle: | Header | Description | |---|---| | X-RateLimit-Limit | Maximum requests allowed per window | | X-RateLimit-Remaining | Requests remaining in the current window | | X-RateLimit-Reset | Unix timestamp when the window resets | To adjust an integration's rate limit, open the integration detail page in Administration > Integrations and update the Rate Limit field. You can also contact GrowerIQ support to request a temporary increase for data migration or backfill scenarios. !!! info "Design for 429 responses" Build retry logic into every integration. When you receive a 429, read the X-RateLimit-Reset header and wait until the window resets before retrying. Exponential backoff with jitter is recommended for high-throughput integrations. IP Allowlisting IP allowlisting restricts API access to requests originating from specific network addresses. When enabled, any request from an IP not in the allowlist receives 403 Forbidden. - Format: CIDR notation (e.g., 10.0.0.1/32 for a single IP, 192.168.1.0/24 for a subnet) - Maximum entries: 50 per integration - Default: Disabled (all IPs permitted) To configure an allowlist: 1. Navigate to Administration > Integrations and open the integration. 2. Locate the IP Allowlist section. 3. Add one or more CIDR entries. 4. Save. !!! tip "Best suited for static IPs" IP allowlisting is most useful for integrations running on infrastructure with predictable, static IP addresses: on-premises ERP systems (SAP, Dynamics), cloud services with published IP ranges, or VPN exit nodes. For serverless or dynamic-IP environments, rely on API key authentication and scope restrictions instead. !!! warning "Lock yourself out? Remove the entry." If an integration stops working after enabling IP allowlisting, verify that the calling system's egress IP matches an entry in the allowlist. Cloud providers sometimes rotate IPs without notice. Remove or update the stale entry to restore access. Integration Security tab showing IP address restriction toggle and lifecycle action buttons Responding to a Security Incident If you suspect an integration's credentials have been compromised or you observe unexpected API activity, follow these steps: 1. Suspend immediately Open the integration in Administration > Integrations and click Suspend. Suspension takes effect instantly, invalidating the API key and blocking all requests. Configuration and logs are preserved. 2. Review API logs Navigate to QA > Integration API Logs and filter by the affected integration. Look for: - Unusual request volumes or patterns - Requests from unexpected IP addresses - Access to scopes the integration should not be using - Requests outside normal operating hours 3. Check webhook delivery logs If the integration has webhook subscriptions, review the delivery log for the subscription. Verify that payloads were not redirected to an unauthorized endpoint. 4. Regenerate credentials Generate a new API key and, if applicable, a new webhook signing secret. Store the new credentials in your secrets manager before distributing them. 5. Contact GrowerIQ support Share the relevant Request IDs from the API logs with GrowerIQ support. The support team can correlate server-side logs and help determine the scope of the incident. 6. Reactivate with new credentials Once the investigation is complete and new credentials are deployed, a different administrator (not the one who suspended) must reactivate the integration. This dual-control requirement ensures no single person can suspend and reactivate without oversight. !!! info "Suspension is non-destructive" Suspending an integration does not delete its configuration, scope assignments, webhook subscriptions, or logs. Only the API key is invalidated. After reactivation with new credentials, the integration resumes normal operation. Quarterly Review Checklist Schedule a quarterly review of all active integrations. Use this checklist to ensure your security posture stays current: - [ ] Are all active integrations still in use? Suspend or delete any that are no longer needed. - [ ] Do assigned scopes still match actual usage? Remove scopes that are no longer required. - [ ] Are credentials held only by authorised personnel? Rotate credentials if team members have changed. - [ ] Are rate limits appropriate for current traffic patterns? Adjust up or down based on API log data. - [ ] Is IP allowlisting enabled for integrations with static infrastructure? Add it where feasible. - [ ] Have partner contacts changed? If the integration is managed by a third party, confirm that only current contacts hold credentials and rotate if needed. !!! tip "Export a summary for your SOC 2 auditor" The quarterly review checklist aligns with SOC 2 access-review requirements. Document your findings and retain them alongside your other compliance artefacts.

Last updated on Apr 01, 2026