.png)
Tyler Technologies Integration Guide
Integrate Tyler products and Socrata data with enterprise systems through product-specific REST APIs, scheduled synchronization, exports, and documented callbacks.
Tyler Technologies integration options at a glance
Tyler Technologies does not expose one uniform integration model across Munis, EnerGov, Odyssey, Tyler SIS, and Tyler Data & Insights/Socrata. REST APIs are the clearest confirmed mechanism, with Socrata providing APIs for querying, filtering, pagination, and data publication. Scheduled workflows can support incremental or batch synchronization, while exports can provide JSON, CSV, or other supported formats. Some Tyler products may expose callbacks or notifications, but these must be verified for the selected product and tenant. Martini can securely consume these interfaces, store environment-specific credentials, transform Tyler data, apply business rules, expose controlled APIs, and manage retries and reconciliation.
| Integration point | Supported by Tyler Technologies? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Socrata REST APIs expose datasets and views for querying, filtering, pagination, and publication. Tyler transactional products may expose product-specific REST APIs with different resources and write permissions. | Martini can consume Tyler or Socrata REST APIs, configure authentication by environment, transform responses, and expose a controlled REST API when another system needs an integration endpoint. |
| Authentication | Limited | Socrata supports application tokens and authenticated access to private resources through OAuth 2.0. Tyler product authentication may use OAuth, API keys, or tenant credentials depending on the product. | Martini stores tokens, client details, keys, and tenant settings in secrets or environment configuration and applies the authentication method documented for the selected product. |
| Bulk / async / batch APIs | Limited | Socrata query and export-oriented access supports scheduled and batch synchronization. Bulk capabilities for Munis, EnerGov, Odyssey, or other transactional products are product-specific. | Martini can schedule batch workflows, paginate large results, maintain checkpoints, and reconcile source identifiers and modification timestamps. |
| Webhooks / outbound callbacks | Limited | Some Tyler applications may provide product-specific callbacks or notifications, but no general Tyler-wide webhook catalog was confirmed. | Where documented, Martini can expose an API workflow to receive callbacks, validate and deduplicate requests, retrieve authoritative data, and route the event for processing. |
| File / attachment APIs | Limited | Socrata supports data exports in supported formats. General Tyler document or attachment APIs for transactional products were not confirmed. | Martini can process approved JSON, CSV, or other exports and route files through workflows, but product-specific attachment interfaces must be verified first. |
| SDKs | Limited | Product-specific SDKs or Socrata client-library references may exist, but no single Tyler-wide SDK was confirmed. | Martini can consume documented HTTP APIs directly, avoiding a dependency on a vendor SDK where the API is available. |
| GraphQL APIs | Not confirmed | No general Tyler or Socrata GraphQL interface was confirmed. | Martini supports GraphQL consumption generally, but a Tyler GraphQL integration should not be designed unless the selected product documents it. |
| SOAP APIs | Not confirmed | No current vendor-wide SOAP interface was confirmed; older implementation-specific interfaces should not be assumed. | Martini can consume SOAP services when a Tyler product explicitly documents one, but SOAP is not a default Tyler integration method. |
How Tyler Technologies exposes data and business events
Tyler REST APIs
REST is the clearest confirmed integration mechanism across the Tyler ecosystem through Socrata Open Data APIs and selected product-specific API programs. Socrata supports HTTP access to datasets and views, including querying, filtering, pagination, and publication subject to permissions.
Martini implementation pattern
Martini implementation pattern: configure the selected Tyler or Socrata endpoint and environment-specific authentication, invoke it from a workflow, validate and transform the response, apply business rules, and write the result to a target system or expose a controlled Martini API.
Implementation sequence
Scheduled synchronization
Socrata access is primarily request-driven, so scheduled workflows are appropriate for polling datasets or views. Incremental synchronization can use a documented modification timestamp, stable filter, or bounded overlap window where available.
Martini implementation pattern
Martini implementation pattern: a scheduler starts the workflow, the workflow retrieves pages of source data, compares source identifiers and modification values with the target, and records a successful checkpoint only after processing completes.
Implementation sequence
Batch exports
Socrata supports querying and exporting dataset resources in supported formats, making batch processing useful for large result sets and reconciliation. Export format, limits, and permissions depend on the resource.
Martini implementation pattern
Martini implementation pattern: retrieve an approved export, parse JSON, CSV, or another supported format, validate the structure, transform rows into the target model, and compare source identifiers to detect additions, changes, and removals.
Implementation sequence
Product-specific callbacks
General Tyler webhook coverage was not confirmed. Individual Tyler applications may provide outbound callbacks or notifications for selected events, with semantics and retry behavior defined by that product.
Martini implementation pattern
Martini implementation pattern: expose a protected API workflow, authenticate and validate the incoming request, deduplicate it, retrieve the authoritative Tyler resource, and process the event asynchronously where appropriate.
Implementation sequence
Common Tyler Technologies integration patterns
Pattern 1: Synchronize Socrata datasets to Power BI
When to use this pattern
Use this pattern when Tyler Data & Insights/Socrata is the source for operational dashboards or public-sector reporting. It is suitable for scheduled synchronization where the resource provides an incremental field or a bounded overlap strategy can be applied.
Integration direction
Example Mapping
| Tyler Technologies Field | Canonical Field | Target Field |
|---|---|---|
| dataset identifier | sourceDatasetId | source identifier |
| row identifier | sourceRecordId | record key |
| updated timestamp | lastModifiedAt | refresh watermark |
| dataset column values | measures and dimensions | reporting fields |
Martini implementation pattern
A scheduler starts a Martini workflow that queries the Socrata resource with pagination and an incremental predicate. Martini maps rows into a reporting shape, validates required columns, excludes sensitive fields where required, and sends the result to the selected Power BI ingestion or intermediate store. Retries use backoff, while rejected rows and checkpoint state support reconciliation.
Martini capabilities used
- workflows
- scheduled triggers
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- error handling
Pattern 2: Synchronize EnerGov Work Orders to Salesforce
When to use this pattern
Use this pattern when permitting, inspection, licensing, or community-development information needs to support constituent or service workflows in Salesforce. EnerGov API availability and object coverage must be confirmed for the implementation.
Integration direction
Example Mapping
| Tyler Technologies Field | Canonical Field | Target Field |
|---|---|---|
| Work Order identifier | sourceWorkOrderId | external ID |
| status | workOrderStatus | case or service status |
| property or applicant reference | partyReference | account or contact reference |
| last modified timestamp | lastModifiedAt | synchronization checkpoint |
Martini implementation pattern
Martini retrieves approved EnerGov data through its documented interface or export, normalizes identifiers and statuses, and upserts Salesforce data using the source identifier. Business rules can restrict sensitive fields and determine which status changes are publishable. Transient failures are retried; validation failures are isolated for review.
Martini capabilities used
- API consumption
- workflows
- data mapping
- business rules
- idempotent upserts
- error handling and retries
Pattern 3: Reconcile Munis data with Workday
When to use this pattern
Use this pattern when an organization needs scheduled reconciliation between Munis and Workday for workforce, organization, payroll, finance, or procurement-related information. Exact objects and write permissions require product-specific confirmation.
Integration direction
Example Mapping
| Tyler Technologies Field | Canonical Field | Target Field |
|---|---|---|
| Munis employee or organization identifier | sourceReference | worker or organization reference |
| effective date | effectiveFrom | effective date |
| department or fund | organizationalUnit | supervisory organization or cost center |
| record status | sourceStatus | worker or financial status |
Martini implementation pattern
A scheduled Martini workflow retrieves approved Munis and Workday extracts or API resources, applies effective-date and code-conversion rules, and compares source identifiers before writing changes. Checkpoints, overlap windows, and reconciliation reports reduce missed updates and duplicate processing.
Martini capabilities used
- scheduled workflows
- API consumption
- file processing
- data transformation
- business rules
- reconciliation
- monitoring
Pattern 4: Process a product-specific Tyler callback
When to use this pattern
Use this pattern only when the selected Tyler product documents outbound callbacks for the required event. It provides near-real-time processing while retaining Tyler as the source of authoritative business data.
Integration direction
Example Mapping
| Tyler Technologies Field | Canonical Field | Target Field |
|---|---|---|
| callback event identifier | eventId | correlation ID |
| source object identifier | sourceObjectId | external reference |
| event type | eventName | request type |
| source status | authoritativeStatus | workflow state |
Martini implementation pattern
Martini exposes a protected API endpoint to receive the callback, authenticates the sender, deduplicates the event, and retrieves the current Tyler object before updating ServiceNow. The workflow records correlation data, handles out-of-order notifications conservatively, and routes failed deliveries to retry or reconciliation processing.
Martini capabilities used
- API exposure
- webhook consumption
- authentication
- deduplication
- data mapping
- workflow orchestration
- error handling
Applications commonly integrated with Tyler Technologies
Tyler integrations are product- and deployment-specific. The following applications represent practical enterprise architecture patterns, but endpoint availability, permissions, and object coverage should be confirmed for the customer’s Tyler product and environment.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Combine permitting, licensing, or constituent-related information with CRM and service workflows. | Tyler Technologies → Martini → Salesforce | Martini consumes the applicable Tyler API or export, maps Tyler identifiers and status fields to Salesforce objects, applies privacy and validation rules, and handles rejected or duplicate updates through a reconciliation workflow. |
| ServiceNow | Coordinate operational requests and service processes with selected Tyler application data. | Tyler Technologies → Martini → ServiceNow | A scheduled or callback-driven Martini workflow retrieves authoritative Tyler data, maps it to ServiceNow requests or records, preserves source identifiers, and retries transient failures while routing validation errors for review. |
| Workday | Reconcile workforce, organization, payroll, finance, or procurement-related information alongside Tyler ERP processes. | Tyler Technologies → Martini → Workday | Martini orchestrates scheduled extracts or documented APIs in both systems, normalizes organization and employee identifiers, applies effective-date rules, and records checkpoints for repeatable reconciliation. |
| Microsoft Power BI | Make Tyler Data & Insights/Socrata datasets available for public-sector dashboards and performance reporting. | Tyler Technologies → Martini → Microsoft Power BI | Martini queries Socrata datasets or views with pagination and incremental filters, transforms rows into a reporting model, and delivers the result to the selected Power BI ingestion or intermediate data-store process. |
| Esri ArcGIS | Combine permitting, property, infrastructure, or location information with geographic analysis and mapping. | Tyler Technologies → Martini → Esri ArcGIS | Martini retrieves approved Tyler data, validates geographic attributes, maps identifiers and coordinates to the ArcGIS model, and manages partial failures through retry and reconciliation logic. |
| NetSuite | Exchange finance, billing, or procurement-related information where NetSuite is used alongside Tyler systems. | Tyler Technologies → Martini → NetSuite | A Martini workflow coordinates product-specific Tyler extracts or APIs with NetSuite requests, applies accounting and identifier mappings, and uses checkpoints and idempotent writes to prevent duplicate transactions. |
How to build a Tyler Technologies integration in Martini
Objective
Define the Tyler product, module, tenant, deployment model, API version, base URL, and permitted read or write operations before designing the canonical model.
Instructions in Martini
- Confirm whether the source is Socrata, Munis, EnerGov, Odyssey, Tyler SIS, or another product
- Obtain the product-specific API or export documentation
- Confirm tenant, environment, permissions, and data privacy requirements
Objective
Set up the authentication method and environment-specific endpoint configuration without embedding credentials in workflows.
Instructions in Martini
- Configure OAuth, application tokens, API keys, or tenant credentials as documented
- Store secrets and tokens in Martini environment configuration
- Apply least-privilege access and confirm token expiration and refresh behavior
Objective
Select a trigger based on the confirmed Tyler capability and synchronization objective.
Instructions in Martini
- Use a scheduled trigger for Socrata polling or batch exports
- Use a documented callback endpoint only when the Tyler product supports it
- Define checkpoint, overlap, and duplicate-handling behavior
Objective
Call the Tyler or Socrata interface and obtain complete, authoritative source data.
Instructions in Martini
- Invoke the documented REST resource or retrieve the approved export
- Implement deterministic pagination and appropriate filters
- Capture source identifiers, timestamps, request IDs, and response metadata where available
Objective
Transform product-specific Tyler payloads into a stable canonical model and target-system representation.
Instructions in Martini
- Map actual Tyler object fields to canonical fields
- Normalize dates, codes, identifiers, and status values
- Validate required fields and isolate malformed rows
Objective
Apply business, privacy, routing, and synchronization rules before writing to downstream systems.
Instructions in Martini
- Filter fields according to tenant, privacy, and data-sharing requirements
- Determine create, update, reconciliation, or ignore actions
- Use stable external identifiers and idempotent processing
Common Tyler Technologies data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Datasets | Published data resources in Tyler Data & Insights/Socrata. | Microsoft Power BI, Esri ArcGIS, data warehouses, reporting applications | Martini queries, filters, paginates, transforms, and synchronizes dataset contents using the resource’s documented API and permissions. |
| Views | Dataset or visualization-backed API resources exposed through Socrata. | Reporting platforms, analytics stores, downstream APIs | Martini treats the view as a source resource, applies incremental queries where supported, and maps returned rows into a target model. |
| Columns | Fields defined within a Socrata dataset or view. | Data warehouses, reporting models, validation services | Martini uses column metadata to validate mappings, normalize names and types, and detect schema changes. |
| Rows | Individual data records returned from a dataset or view. | Power BI, databases, CRM, GIS, operational applications | Martini processes rows in pages or batches, applies transformations and business rules, and writes idempotently using stable source identifiers. |
| Work Orders | Operational records commonly associated with EnerGov and community-development processes. | Salesforce, ServiceNow, GIS, reporting databases | Martini can process Work Orders only through the documented EnerGov interface or approved export, with product-specific fields and permissions confirmed first. |
| Cases | Justice-system records commonly associated with Odyssey implementations. | ServiceNow, reporting systems, approved justice or records platforms | Martini applies strict access, privacy, field-minimization, and audit rules while using only documented Odyssey operations or approved extracts. |
Authentication and security considerations
Product-specific authentication
Tyler authentication varies by product, tenant, and API program. Socrata supports application tokens and OAuth 2.0 for authenticated access to private resources; other Tyler products may require OAuth, API keys, or tenant credentials.
Secrets and least privilege
- Store credentials, tokens, client details, and tenant settings in Martini secrets or environment configuration.
- Confirm scopes, token expiration, refresh behavior, and service-account permissions for the selected product.
- Minimize sensitive court, education, personnel, financial, and constituent data transferred between systems.
Operational considerations for Tyler Technologies integrations
Reliability and scale
- Implement deterministic pagination, bounded concurrency, and backoff for rate limits and transient failures.
- Use stable identifiers, idempotent writes, event deduplication, and persisted checkpoints.
- Prefer incremental filters or bounded overlap windows instead of repeatedly retrieving complete datasets.
Change management
Validate required fields and monitor schema, column, endpoint, and product-version changes. Distinguish authentication, validation, conflict, rate-limit, and server errors, and route rejected data to reconciliation workflows.
Privacy and testing
Test against a non-production environment where available, restrict logs and payload exposure, and confirm retention, audit, jurisdiction, and data-sharing obligations before deployment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond a script
Tyler integration requirements often vary by product, tenant, and licensed module. Martini provides a maintainable workflow layer for API calls, scheduled processing, callbacks, transformations, business rules, checkpoints, and reconciliation without hard-coding the entire integration in a single script.
Reusable and controlled integration assets
- Centralize authentication and environment configuration.
- Reuse mappings, validation, error handling, and retry behavior across workflows.
- Expose controlled APIs when downstream systems should not access Tyler directly.
- Monitor processing and isolate rejected records for operational follow-up.
Frequently asked questions
Integration depends on the Tyler product and deployment. The clearest confirmed method is REST API consumption, especially through Tyler Data & Insights/Socrata for datasets and views. Scheduled queries, batch exports, and product-specific callbacks may also be used where documented. Martini can orchestrate retrieval, transformation, validation, synchronization, and reconciliation.
Yes. Martini can integrate with Tyler by consuming the applicable Tyler or Socrata REST API, processing approved exports, and receiving documented product-specific callbacks. A product, tenant, authentication method, and permitted operations must be confirmed before implementation.
No. A dedicated Tyler Technologies connector is not required. Martini can use Tyler’s confirmed native integration mechanisms, including REST APIs, Socrata queries and exports, documented authentication methods, and product-specific callbacks where available.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Tyler Technologies. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Tyler, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
REST APIs are the primary recommended method where documented, with Socrata providing query, filtering, pagination, and publication capabilities. Scheduled synchronization and exports are useful for batch access. GraphQL and a current vendor-wide SOAP API were not confirmed, and callbacks should be treated as product-specific.
No general all-events webhook capability was confirmed. Some Tyler applications may provide outbound callbacks or notifications for selected events. Martini can receive those callbacks through a protected API workflow, but event coverage, ordering, retries, and duplicate behavior must be verified for the specific product.
Martini can run scheduled workflows that query Tyler or Socrata resources, use pagination and an incremental timestamp or other stable filter, map results, and write them to a target system. Checkpoints, overlap windows, stable source identifiers, and reconciliation logic help manage late updates and duplicates.
Yes. Martini can expose a controlled REST API that abstracts a Tyler or Socrata resource, applies authorization and field-level filtering, transforms responses, and orchestrates calls to the source. This is useful when consumers should not access Tyler directly.
Related Martini documentation
APIs
Workflows
Plan a Tyler Technologies integration
Identify the Tyler product, tenant, data objects, authentication method, and approved interface first. Martini can then provide the workflows, APIs, mappings, security controls, and operational handling needed for a maintainable integration.