Skip to main content

SDK-Based Workflows

Entrupy Mobile SDKs (iOS and Android) enable you to integrate Entrupy's advanced item authentication and fingerprinting capabilities directly into your customer-facing applications. This provides a seamless experience within your brand's environment, allowing end-users (e.g., sellers on your marketplace, buyers comparing an item, or your own staff using an internal app) to perform these actions.

  • Authenticating Users: End-users of your platform or application (e.g., marketplace sellers, consumers, internal staff using a custom-built tool).
  • Capture Method: The SDK handles the image/data capture process, guided by your application's UI and workflow.

All data generated via the Entrupy app, including authentication results and fingerprinting records, can be accessed via the Entrupy API. This enables integration with your backend systems for reporting, inventory management, and other operational needs by using the customer_item_id provided during the app workflow. See API Integration for more details.

Workflows for In-App Listing​

These workflows are designed for scenarios where an individual item's authentication is integrated directly into your application's listing or transaction process, typically initiated by the end-user (e.g., a seller on your marketplace).

Pre-Listing Authentication​

This workflow allows users to authenticate items using the SDK embedded in your application before an item is made available for sale.

  • Use Case: Enable sellers on your platform to authenticate items directly within your marketplace app as part of the listing creation process.
  • Benefits: Ensures authenticity and builds consumer confidence from the moment an item is listed. Can be a prerequisite for listing or displayed as a mark of trust.
  • Trigger: User initiates a new item listing within your app.
  • Technical Implementation:
    • The core technical architecture, SDK responsibilities, API interactions, and step-by-step implementation largely follow the "General SDK Authentication Pattern (for In-App Listing)" described below.
    • Your application's business logic will gate the completion of the listing process based on a successful authentication result.

Post-Sale Authentication​

This workflow allows users to authenticate items using the SDK embedded in your application after an item has been sold but before it is shipped.

  • Use Case: Your platform prompts a seller to authenticate an item using an SDK-integrated tool after a sale occurs.
  • Benefits: Lowers the initial barrier to listing (authentication is not required upfront) while still ensuring authenticity before the item reaches the buyer.
  • Trigger: An item is sold; your platform notifies the seller to authenticate the item before proceeding with shipment.
  • Technical Implementation:
    • The core technical architecture, SDK responsibilities, API interactions, and step-by-step implementation largely follow the "General SDK Authentication Pattern (for In-App Listing)" described below.
    • Your application's business logic will gate the shipping process based on a successful authentication result.

General SDK Authentication Pattern (for In-App Listing)​

The following describes the general technical flow applicable to both Pre-Listing and Post-Sale authentication workflows integrated into your application.

  • Challenge: Authenticate items efficiently and reliably at various points in an item's lifecycle, initiated by a user within your app.
  • Solution: Use Entrupy's SDK for image and data capture integrated into your application, and the Entrupy API for session management and result retrieval.

Technical Architecture & Roles​

  • Entrupy SDK Responsibilities:
    • Presenting the Entrupy Capture Flow UI.
    • Securely uploading images and data to Entrupy's systems.
    • Optionally, displaying results and certificates via the SDK's Detail View.
  • Entrupy API Responsibilities:
    • Providing session authorization endpoints for the SDK.
    • Allowing lookup of status and results.
    • Delivering results, Catalog Data, and Certificate Information to internal systems.
  • Your Application's Responsibilities:
    • Managing the user experience around the chosen workflow (pre-listing or post-sale).
    • Passing customer_item_id.
    • Implementing business logic based on results (e.g., allow listing, permit shipment).

Step-by-Step Implementation​

Prerequisites:

  • Active Entrupy API credentials with SDK support.
  • Entrupy Mobile SDK integrated into your application.

Step 1: Install and Configure the SDK

  • Integrate the appropriate Entrupy Mobile SDK into your application.
  • Follow the setup instructions for your chosen platform.

Step 2: Backend Token Generation

  • Your backend is responsible for securely authorizing your user and requesting credentials from Entrupy's API to authorize the client application.
  • Your backend calls an authorization endpoint (e.g., POST /v2/integrations/authorize-user) to sign an authorization request from your mobile client.
  • The API returns a signed request that your backend then passes to your mobile application to use with the SDK.

Step 3: Launch and Complete Capture Flow

  • Your mobile application, using the SDK, launches the Entrupy Capture Flow.
  • Provide a unique customer_item_id for each item to track it and correlate results via API later. (If no ID is supplied, your application can pass the generated Entrupy ID to your backend).
  • The user follows the on-screen instructions to photograph the item and submits all images to Entrupy's systems.

Step 4: Monitor Results

  • After data submission, monitor authentication status and access results using:
    • The SDK's Detail View (automatically receives updated results).
    • Webhooks configured to notify your backend of status changes.
    • Polling the Entrupy API using the customer_item_id or Entrupy ID.
  • Interpret the result (e.g., "Authentic," "Unidentified").
  • Display results and certificate information in your app.
  • Update your backend systems and trigger appropriate business logic based on the specific workflow (pre-listing or post-sale).

Workflows for Batch Listing (Data Imports, Integrations)​

These workflows are designed for platforms that handle a high volume of items requiring authentication, often integrating with existing inventory management and prossing pipelines where items might be imported or processed in batches. The key is adapting Entrupy's SDK-based authentication to fit into your platform's established processes, particularly concerning when an item is registered in your system and receives its unique identifier (customer_item_id).

Note: While these are termed "Batch Listing" workflows, the authentication step can technically occur at any point in your process that makes sense – before items are listed, after they are imported into your system but before going live, or even for existing inventory. The scenarios below focus on the timing of Entrupy authentication relative to when your platform assigns its customer_item_id.

Your platform is responsible for managing the "batch" or queue of items. Entrupy provides the SDK for capture and the API for results.

Authentication after record creation is recommmended as it's simpler, but before and after are both possible.

Authentication After Record Creation​

Workflow: Your platform first registers items (e.g., from a bulk import, data feed, or initial seller listing creation without immediate authentication), assigning each a unique customer_item_id. These items are then queued or flagged for authentication using an SDK-integrated tool, often by an internal operator or as a prompted step for a seller.

Implementation:

  1. Item Record Exists: The item exists in your system with a known customer_item_id.
  2. Initiate SDK Capture: Your SDK-integrated application (used by an operator or end-user) identifies an item for authentication (e.g., by scanning a barcode linked to your customer_item_id, selecting from a list). The customer_item_id is passed to the Entrupy SDK when launching the Capture Flow.
  3. Image Capture & Submission: The user completes image capture via SDK.
  4. Result Retrieval: Your backend monitors for results using the customer_item_id (via API polling or webhooks).
  5. Platform Update: Your system updates the item's record with the authentication outcome.

customer_item_id Handling: Passed to SDK at the start. This is the most direct method for correlation.

Operational Alternative for Entrupy App Users: If your team uses the Entrupy App directly for authentications rather than an SDK-integrated custom application, refer to the High-Volume Processing with the Entrupy App guide for a comparable operational pattern.

Authentication Before Record Creation​

Workflow: An item undergoes authentication using an SDK-integrated tool before it's formally registered and assigned a permanent customer_item_id in your platform's primary inventory or listing system. This might occur, for example, during an initial intake process where items are scanned for authenticity first.

Implementation:

  1. Initiate SDK Capture (No Initial customer_item_id): Your SDK-integrated app starts the Entrupy Capture Flow. A customer_item_id is typically not supplied to the SDK at this stage.
  2. Image Capture & Submission: The user completes image capture. The SDK provides an Entrupy-generated session identifier (Entrupy ID) upon submission.
  3. Store Entrupy ID: Your application must capture and temporarily store this Entrupy ID, associating it with the physical item (e.g., via a temporary tag, a record in a staging database or a local cache in the app).
  4. Item Record Creation & customer_item_id Assignment: At a later point, your platform formally creates a record for the item and assigns its permanent customer_item_id.
  5. Link customer_item_id to Entrupy Record: Use the forthcoming v2 API endpoint to update the Entrupy authentication record by adding your customer_item_id, using the stored Entrupy ID to identify the session. (Alternatively, if this endpoint is not yet available, you must maintain an internal mapping between the Entrupy ID and your customer_item_id for result lookup).
  6. Result Retrieval: Poll for results using the Entrupy ID or, once linked via API, your customer_item_id.
  7. Platform Update: Your system updates the newly created item's record with the authentication outcome.

customer_item_id Handling: Entrupy-generated ID is captured initially. Your platform's customer_item_id is linked retrospectively via an API call or maintained in your own mapping.

Fingerprinting Workflows​

Entrupy's fingerprinting technology allows unique item identification by capturing surface characteristics, creating a digital identifier for robust item comparison and establishing a secure chain of custody. This section focuses on SDK integration for these purposes.

  • Primary Use Cases:
    • Supply Chain Integrity: Register an item's fingerprint at one point in its journey (e.g., by the seller pre-shipment or by platform staff during intake) and compare it at another point (e.g., by a buyer upon receipt, during returns processing by platform staff) to ensure it's the same item.
    • Buyer Confidence: Allow buyers to compare an item's fingerprint upon receipt to confirm they received the exact item that was originally fingerprinted.
  • Note on Warehouse Returns: For returns fraud situations handled exclusively by internal staff within a warehouse environment using Entrupy-provided hardware, using the Entrupy App Workflows might be more suitable. SDK-based fingerprinting is ideal for integrations into customer-facing apps or custom internal tools that may not use the specialized Entrupy App hardware setup.

Fingerprint Registration​

This workflow describes how an item's unique fingerprint is initially captured and stored using an SDK-integrated application. This is typically done when an item is first processed by your platform or a seller.

Registration Methods:

  1. Concurrent with Authentication: When an item is authenticated using the SDK (as in the "Workflows for In-App Listing" or "Workflows for Batch Listing" described above), its fingerprint can often be automatically registered as part of that same SDK capture session. This is efficient if authentication is already part of your workflow.
  2. Dedicated Fingerprint Registration Flow: The SDK also supports a specific flow focused solely on fingerprint registration. This flow may require capturing fewer images than a full authentication and can be used for items that Entrupy may not support for authentication but for which fingerprinting is desired, or when you want a distinct, faster registration step.

Technical Architecture & Roles (Registration):

Step-by-Step Implementation (Registration):

  1. Prerequisites: Active Entrupy API credentials with SDK support, and fingerprinting enabled for your account. Entrupy Mobile SDK integrated into your application.
  2. Token Generation: Your backend obtains an SDK session token from the Entrupy API.
  3. Launch Capture Flow: Your app launches the SDK's capture flow (either a combined authentication/fingerprinting flow or a dedicated registration flow), initialized with the customer_item_id and session token.
  4. User Captures Data: The user follows on-screen instructions.
  5. Record Registration: SDK uploads data. Your backend should record that the item associated with customer_item_id has been fingerprinted, typically confirmed via API/webhook.

Fingerprint Comparison​

This workflow describes how a previously registered fingerprint is compared against a new scan of the item, typically by a different user or at a later stage (e.g., a buyer receiving an item, or during returns intake).

Technical Architecture & Roles (Comparison):

Step-by-Step Implementation (Comparison):

  1. Prerequisites: Active Entrupy API credentials with SDK support, and fingerprinting enabled for your account. Entrupy Mobile SDK integrated into your application.
  2. Token Generation: Your backend obtains an SDK session token from the Entrupy API.
  3. Launch Capture Flow: Your app launches the SDK capture flow in "comparison" mode, referencing the customer_item_id of the item whose fingerprint was previously registered.
  4. User Captures Data: The user follows on-screen instructions to capture new fingerprint data from the item in hand.
  5. Monitor & Display Results: SDK uploads data. Your backend queries the API (or uses webhooks) for the comparison outcome (e.g., Match/No Match). Your app displays this result to the user.

Next Steps​