Ellipse Gradient for Header

Nearmap Integration Guide

Connect Nearmap aerial imagery, coverage, metadata, and map services with enterprise workflows through APIs and scheduled synchronization.

Nearmap integration options at a glance

Nearmap provides REST APIs for imagery, metadata, coverage, and related geospatial resources. Depending on the customer’s product entitlement, imagery may also be consumed through tile services or OGC-style map services such as WMS or WMTS. Image and tile responses can be processed as content or references, while account-specific API credentials are used according to the selected service’s authentication requirements. A general webhook, bulk API, direct database connection, or GraphQL and SOAP interface was not confirmed. Martini can call Nearmap services, validate geographic parameters, transform metadata, schedule coverage checks, persist synchronization state, and expose a normalized REST API to downstream applications.

Integration pointSupported by Nearmap?Common use casesHow Martini supports it
REST APIsYesRetrieve imagery, image metadata, coverage information, and related geospatial resources for locations, areas, dates, or product conditions.Martini can consume Nearmap REST APIs, validate requests, map responses, apply business rules, and expose normalized downstream APIs.
Map-service protocolsLimitedConsume imagery and geospatial layers through tile services or OGC-style services such as WMS or WMTS where enabled by the relevant Nearmap product.Martini can call supported HTTP-based map services and orchestrate their responses, but protocol availability and subscription entitlement must be confirmed.
Image and tile retrievalLimitedRetrieve image content, tile data, metadata, or imagery URLs for specified geographic areas.Martini can process image or tile responses, persist permitted references, and route content to approved downstream systems while applying size and storage rules.
Scheduled synchronizationYesPoll coverage or metadata endpoints to identify newly available imagery or changes when event notifications are not available.Martini can trigger scheduled workflows, compare responses with stored state, enforce idempotency, and notify downstream applications.
File and attachment accessLimitedHandle imagery returned as binary content or retrieve permitted image resources through HTTP-based services; a general attachment API was not confirmed.Martini can route binary responses or references and integrate with approved storage or content systems, subject to Nearmap licensing and retention rules.
AuthenticationLimitedUse account-specific API keys or access credentials, with key placement and authorization behavior determined by the selected Nearmap service.Martini can store Nearmap credentials as environment-specific secrets and apply the required header or query-parameter configuration without hard-coding credentials.
Webhooks and outbound callbacksNot confirmedA general Nearmap webhook or outbound event-notification framework was not confirmed, so new imagery should not be assumed to generate push events.Martini can use scheduled polling or on-demand API calls instead of relying on unconfirmed callbacks.
Bulk or asynchronous APIsNot confirmedNo general bulk or asynchronous Nearmap API was confirmed; large-area and high-volume access may depend on product, licensing, and quota terms.Martini can process bounded requests incrementally and persist progress, but bulk behavior must be validated against the applicable Nearmap service.

How Nearmap exposes data and business events

Nearmap REST APIs

Nearmap provides REST API access to imagery, metadata, coverage, and related geospatial resources. Exact endpoints, parameters, response formats, and entitlements vary by Nearmap product and account.

Martini implementation pattern

Martini implementation pattern: a workflow receives a location or synchronization request, retrieves the Nearmap credential from environment configuration, calls the selected REST endpoint, validates the response, maps provider data to a canonical model, and returns or stores the result.

Implementation sequence

Receive a location, area, date, or synchronization request
Validate coordinates, geometry, product parameters, and authorization
Retrieve the Nearmap credential from secure environment configuration
Call the applicable Nearmap REST endpoint
Validate the HTTP response and classify entitlement or quota errors
Map imagery or metadata to the target model and persist permitted state

Nearmap map services

Nearmap imagery may be available through tile services or OGC-style map services such as WMS or WMTS when enabled by the applicable product subscription. Availability must be confirmed for the customer’s service.

Martini implementation pattern

Martini implementation pattern: a workflow accepts a map or tile request, validates the requested layer and geographic bounds, calls the permitted Nearmap service, and returns a controlled response or service reference to the consuming application.

Implementation sequence

Receive a map-layer or tile request
Validate the layer, bounds, coordinate system, and requested dimensions
Load the configured Nearmap service details and credentials
Call the supported Nearmap map or tile service
Apply payload-size, entitlement, and response validation rules
Return the permitted tile, map response, or normalized service reference

Nearmap image and tile retrieval

Nearmap services can return imagery, image tiles, metadata, or URLs for permitted resources. A general-purpose attachment API was not confirmed, and binary handling depends on the selected service.

Martini implementation pattern

Martini implementation pattern: a workflow requests bounded imagery, determines whether the response is binary content or a reference, and routes it to an approved downstream storage or application path without assuming that content may be cached or redistributed.

Implementation sequence

Receive the imagery parameters and downstream destination
Validate area size, image dimensions, date, and product entitlement
Request the permitted Nearmap imagery or tile resource
Determine whether the response is content, metadata, or a URL
Apply storage, retention, and redistribution rules
Deliver the approved output and record diagnostic metadata

Scheduled Nearmap synchronization

Nearmap did not have a confirmed general webhook or outbound event framework in the supplied research. Scheduled polling is therefore the safer approach for coverage or metadata change detection.

Martini implementation pattern

Martini implementation pattern: a scheduler invokes a workflow for configured regions, queries Nearmap coverage or metadata, compares the result with stored identifiers and timestamps, and sends only material changes to downstream systems.

Implementation sequence

Start the workflow on a configured schedule
Read the configured regions or areas of interest
Query Nearmap coverage or metadata endpoints
Compare results with the stored synchronization state
Apply idempotency and late-arriving-data rules
Persist the new state and notify downstream systems

Nearmap authentication

Nearmap API access commonly uses account-specific API keys or access credentials. The exact header or query-parameter format depends on the selected API and subscription, while OAuth 2.0 was not confirmed as a general requirement.

Martini implementation pattern

Martini implementation pattern: credentials are stored as environment-specific secrets, injected into the relevant API configuration, and kept separate from workflow logic. The workflow distinguishes authentication, entitlement, quota, and transient service failures.

Implementation sequence

Confirm the authentication format for the selected Nearmap service
Store the credential as an environment-specific Martini secret
Configure the request with the required header or query parameter
Call a controlled Nearmap endpoint
Classify authentication and entitlement failures separately
Monitor usage without logging credentials or unnecessary imagery payloads

Common Nearmap integration patterns

Pattern 1: Synchronize imagery availability by region

When to use this pattern

Use this pattern when downstream systems need a repeatable view of Nearmap coverage or newly available imagery without relying on unconfirmed webhook notifications. A scheduled workflow checks configured regions, detects changes, and publishes normalized availability information.

Integration direction
Nearmap
Martini
SQL database
Snowflake
Example Mapping
Nearmap FieldCanonical FieldTarget Field
coverage areaareaOfInterestregion_geometry
capture dateimageryCaptureDatecapture_date
imagery identifierimageryReferencenearmap_imagery_id
availability statuscoverageStatusavailability_status
Martini implementation pattern

A scheduler starts the workflow, which reads configured areas, calls Nearmap coverage or metadata APIs, validates the response, and compares stable identifiers, dates, and request parameters with persisted state. Martini applies idempotency and late-arriving-data rules, writes changed metadata to the target store, and retries transient failures while routing quota, entitlement, and malformed-response errors for review.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • SQL persistence
  • idempotency
  • error handling

Pattern 2: Expose an on-demand Nearmap imagery API

When to use this pattern

Use this pattern when internal applications should request Nearmap imagery or metadata through a controlled enterprise endpoint rather than managing Nearmap credentials and provider-specific parameters themselves.

Integration direction
Salesforce
Martini
Nearmap
Example Mapping
Nearmap FieldCanonical FieldTarget Field
coordinates or bounding boxareaOfInterestNearmap geographic parameters
requested datecaptureDateNearmap date parameter
product or layerimageryProductNearmap product parameter
imagery responseimageryResultSalesforce imagery reference
Martini implementation pattern

Martini exposes a REST API that validates caller authorization, coordinates, geometry, dates, product parameters, and request size before invoking Nearmap. The workflow normalizes the response, applies entitlement and selection rules, returns permitted content or a reference, and records correlation data. Invalid requests fail fast, while transient provider failures can be retried with bounded backoff.

Martini capabilities used
  • REST API exposure
  • API consumption
  • request validation
  • data transformation
  • authorization
  • business rules
  • error handling

Pattern 3: Enrich insurance claims with imagery evidence

When to use this pattern

Use this pattern when a claims platform needs the most suitable available imagery, capture date, or coverage status for a property location. It is appropriate when imagery storage and redistribution permissions have been assessed.

Integration direction
Guidewire
Martini
Nearmap
Example Mapping
Nearmap FieldCanonical FieldTarget Field
claim property locationclaimAreaOfInterestNearmap location parameters
claim typeclaimEligibilityMartini business rule
capture dateimageryCaptureDateGuidewire evidence date
imagery URL or referenceimageryReferenceGuidewire claim evidence reference
Martini implementation pattern

Martini receives the claim location and type, checks whether the claim qualifies for an imagery request, and queries Nearmap for relevant metadata or permitted content. The workflow selects the most recent suitable capture, handles no-coverage conditions through a manual-review route, and writes only permitted references or metadata back to Guidewire. Duplicate requests are controlled using claim, location, date, and imagery identifiers.

Martini capabilities used
  • workflow orchestration
  • API consumption
  • data mapping
  • business rules
  • duplicate prevention
  • conditional routing
  • error handling

Pattern 4: Monitor construction or infrastructure projects

When to use this pattern

Use this pattern when active project boundaries must be checked periodically for imagery availability or updated coverage. It supports incremental processing and avoids assuming that Nearmap pushes new-capture events.

Integration direction
ServiceNow
Martini
Nearmap
Example Mapping
Nearmap FieldCanonical FieldTarget Field
project boundaryprojectAreaOfInterestNearmap polygon or bounding box
project statusmonitoringEligibilityMartini routing rule
coverage resultcoverageStatusServiceNow project status
capture datelatestImageryDateServiceNow imagery metadata
Martini implementation pattern

A scheduled Martini workflow retrieves active project boundaries from ServiceNow or an approved project store, validates spatial parameters, and queries Nearmap coverage or metadata. It transforms the result into project-level status, applies rules for inactive or oversized areas, updates ServiceNow only when state changes, and persists checkpoints so a large project set can resume after a failure.

Martini capabilities used
  • scheduled workflows
  • API orchestration
  • spatial parameter validation
  • data transformation
  • change detection
  • checkpointing
  • monitoring

Applications commonly integrated with Nearmap

Nearmap imagery and geospatial metadata can be incorporated into GIS, engineering, insurance, service-management, analytics, and data-platform workflows. The following are practical enterprise architecture patterns; exact protocol compatibility, product entitlements, and object-level behavior should be confirmed for each implementation.

Application Scenario Direction Martini Pattern
ArcGIS Display Nearmap imagery with parcels, infrastructure, field assets, and operational GIS layers. Nearmap → Martini → ArcGIS Martini calls the applicable Nearmap REST or map service, validates geographic parameters, normalizes imagery metadata, and delivers permitted imagery references or service configuration to ArcGIS.
QGIS Provide aerial imagery and map layers for geospatial analysis, planning, and data preparation. Nearmap → Martini → QGIS A Martini workflow retrieves Nearmap imagery or metadata through supported HTTP or map-service protocols, applies coordinate and coverage rules, and returns a format or reference that QGIS can consume where the service entitlement permits.
Autodesk Civil 3D Add aerial context to civil engineering, surveying, site planning, and infrastructure design workflows. Nearmap → Martini → Autodesk Civil 3D Martini receives project boundaries or locations, queries Nearmap for permitted imagery or metadata, and routes normalized references or approved files to the engineering workflow without assuming a direct CRUD integration.
Salesforce Associate property or asset imagery references with accounts, opportunities, claims, or service cases. Salesforce → Martini → Nearmap A Martini workflow accepts a Salesforce location or area of interest, requests relevant Nearmap metadata, selects an eligible capture, and writes the imagery reference, capture date, and status back to Salesforce.
ServiceNow Enrich facilities, infrastructure, or field-service records with imagery references and location context. ServiceNow → Martini → Nearmap Martini receives a ServiceNow location request, validates coordinates and entitlement rules, calls Nearmap, and updates the ServiceNow record with permitted imagery metadata and an auditable request result.
Guidewire Support insurance property and claims workflows with imagery capture dates, location evidence, or imagery references. Guidewire → Martini → Nearmap Martini orchestrates claim-location requests, applies claim eligibility and imagery-selection rules, retrieves Nearmap metadata or permitted content, and returns the result to the relevant Guidewire workflow.
Microsoft Power BI Combine coverage information, imagery-derived metadata, project data, and asset information for reporting. Nearmap → Martini → Microsoft Power BI Martini periodically retrieves Nearmap coverage and metadata, transforms it into an analytics model, and loads permitted metadata into a reporting store or downstream Power BI data source; imagery itself is not assumed to be suitable for direct BI ingestion.
Snowflake Centralize imagery metadata, coverage history, project boundaries, and integration audit data for analytics. Nearmap → Martini → Snowflake A scheduled Martini workflow queries Nearmap, applies change detection and spatial normalization, and writes metadata and synchronization state to Snowflake through the customer’s approved data-loading path.

How to build a Nearmap integration in Martini

Objective

Establish Nearmap access using the account-specific authentication format for the selected API or map service, while keeping credentials and product configuration environment-specific.

Instructions in Martini

  • Confirm API access, product entitlement, coverage, and permitted use with Nearmap.
  • Determine whether the service expects the credential in a header or query parameter.
  • Store the credential in Martini secrets or environment configuration.
  • Keep endpoint and product settings separate between environments.

Objective

Select an integration trigger that matches the Nearmap use case. Because general webhooks and outbound callbacks were not confirmed, use API requests or scheduled workflows for most designs.

Instructions in Martini

  • Use an API-triggered Martini workflow for on-demand imagery or metadata requests.
  • Use a scheduler for coverage and availability synchronization.
  • Do not assume that new imagery generates a Nearmap webhook.
  • Use bounded batches or incremental regions for larger project sets.

Objective

Construct a validated Nearmap request and retrieve imagery, tiles, metadata, coverage, or map-service responses according to the customer’s subscription and service documentation.

Instructions in Martini

  • Validate coordinates, bounding boxes, polygons, dates, layers, and dimensions.
  • Call the applicable Nearmap REST, tile, WMS, or WMTS service.
  • Distinguish image bytes, tile responses, metadata, and resource references.
  • Classify authorization, entitlement, quota, no-coverage, and transient failures separately.

Objective

Use Martini workflow logic to coordinate provider calls, state retrieval, downstream writes, conditional routing, and resumable processing.

Instructions in Martini

  • Retrieve prior synchronization state where change detection is required.
  • Apply request-size and geographic-area limits before calling Nearmap.
  • Use conditional branches for no imagery, manual review, and entitlement failures.
  • Persist checkpoints for multi-region or multi-project processing.

Objective

Convert Nearmap-specific responses into a stable internal model that downstream applications can consume without depending on provider-specific field names or response formats.

Instructions in Martini

  • Map imagery identifiers, capture dates, extents, resolution, and product information.
  • Normalize coordinate reference information and spatial parameter conventions.
  • Preserve permitted provider references and diagnostic metadata.
  • Avoid storing raw binary imagery in transactional databases unless required and authorized.

Objective

Enforce customer-specific selection, authorization, licensing, and synchronization rules before data is returned or persisted.

Instructions in Martini

  • Select the most recent suitable capture when the use case requires it.
  • Reject unsupported regions, oversized requests, and incomplete geometry.
  • Prevent duplicate downstream records using stable imagery and request identifiers.
  • Check whether content may be cached, stored, embedded, or redistributed.

Common Nearmap data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
Aerial imageryRetrieve high-resolution imagery for a location, area, date, or coverage condition.ArcGIS, QGIS, Guidewire, ServiceNow, content storageMartini validates geographic parameters, calls the applicable Nearmap service, and returns permitted image content or a reference while applying licensing and payload-size rules.
Image tilesProvide tiled imagery for web maps and GIS applications.ArcGIS, QGIS, web mapping applicationsMartini can orchestrate tile requests, normalize request parameters, and route tile responses or service references where the Nearmap entitlement supports the selected protocol.
Image metadataDescribe capture date, geographic extent, resolution, coordinate reference information, and available products.Salesforce, ServiceNow, Snowflake, Power BI, GIS platformsMartini maps metadata into a canonical model, applies selection and eligibility rules, and persists permitted fields for search, reporting, or downstream synchronization.
CoverageDetermine where and when Nearmap imagery is available for a region or area of interest.Snowflake, Power BI, project systems, GIS platformsMartini retrieves coverage on demand or on a schedule, compares it with stored state, and emits normalized availability changes without assuming webhook delivery.
Map layersConsume imagery or geospatial layers through supported map-service protocols.ArcGIS, QGIS, web GIS applicationsMartini calls supported map services, validates configuration, and exposes controlled service details or downstream responses according to customer permissions.
Locations or areas of interestRepresent coordinates, bounding boxes, polygons, addresses, or spatial parameters used to request imagery and metadata.Salesforce, ServiceNow, Guidewire, project-management systemsMartini validates geometry, coordinate reference systems, units, and longitude-latitude ordering before constructing Nearmap requests.

Authentication and security considerations

Credentials and access

Nearmap API access commonly uses account-specific API keys or access credentials. The exact header or query-parameter format depends on the selected Nearmap API or map service.

  • Store Nearmap credentials as environment-specific Martini secrets.
  • Do not hard-code keys in workflows, mappings, or exposed API definitions.
  • Confirm account entitlements, geographic coverage, product access, and permitted use before deployment.
  • OAuth 2.0, JWT, and client certificates were not confirmed as general Nearmap requirements.

Controlled exposure

When Martini exposes a normalized Nearmap API, apply caller authentication and authorization separately from Nearmap credentials. Return only imagery, metadata, tiles, or references permitted by the customer’s Nearmap subscription and licensing terms.

Operational considerations for Nearmap integrations

Request limits and geographic parameters

Confirm Nearmap rate limits, concurrency limits, image dimensions, quotas, and area restrictions. Validate coordinates, bounding boxes, polygons, coordinate reference systems, units, and longitude-latitude ordering before making requests.

Synchronization and retries

  • Use stable location, capture, product, and imagery identifiers for idempotency.
  • Persist successful synchronization timestamps and provider identifiers.
  • Retry transient service failures with bounded backoff, but handle authorization, entitlement, and quota errors separately.
  • Use endpoint-specific pagination or response-size handling where applicable rather than assuming a universal model.

Binary content and licensing

Determine whether a service returns image bytes, tiles, metadata, or a URL. Avoid storing large imagery payloads in transactional databases unless required. Confirm caching, retention, embedding, storage, and redistribution permissions before persisting or forwarding imagery.

Change management and testing

Isolate Nearmap request construction and response mapping in reusable workflow components. Test coordinate handling, no-coverage responses, oversized requests, malformed responses, credential failures, quota responses, and changes to endpoint parameters or metadata schemas.

Monitoring

Record permitted diagnostic information such as request time, service used, geographic parameters, imagery identifier, HTTP status, error category, correlation identifier, and downstream persistence result. Do not log API keys or unnecessary imagery payloads.

Why use Martini instead of scripts or point-to-point integrations?

Centralized integration logic

Martini centralizes Nearmap credentials, request validation, geographic parameter handling, response transformation, licensing rules, and downstream delivery in maintainable workflows rather than scattering them across scripts or point-to-point applications.

Reusable enterprise patterns

Teams can reuse workflows for on-demand imagery requests, scheduled coverage synchronization, claim enrichment, project monitoring, and normalized API exposure. This supports consistent handling of idempotency, retries, checkpoints, and audit data.

Controlled APIs and orchestration

Martini can expose a controlled API that shields internal applications from Nearmap-specific request formats and credentials. It can also orchestrate multiple systems, persist synchronization state, apply business rules, and route exceptional cases for review.

Operational maintainability

Compared with isolated scripts, Martini provides a structured place to manage environment configuration, mappings, workflow execution, error handling, monitoring, and deployment. This is particularly useful where imagery payloads, service entitlements, and geographic request rules vary by use case.

Frequently asked questions

How can Nearmap be integrated with enterprise systems?

Nearmap can be integrated through its REST APIs for imagery, metadata, coverage, and related geospatial resources. Depending on the product entitlement, tile services or OGC-style map services such as WMS or WMTS may also be available. Enterprise workflows can use on-demand requests or scheduled polling, while authentication, geographic parameters, licensing, and response handling must follow the selected Nearmap service’s requirements.

Can Martini integrate with Nearmap?

Yes. Martini can consume Nearmap REST APIs and supported map or tile services, validate geographic requests, transform imagery metadata, orchestrate scheduled synchronization, and expose a controlled REST API for internal applications. A dedicated native Martini Nearmap connector was not documented in the supplied research.

Do I need a connector to integrate Nearmap with Martini?

No. A dedicated Nearmap connector is not required. Martini can integrate using Nearmap’s confirmed REST and supported geospatial service interfaces, with workflows handling credentials, validation, request orchestration, transformations, business rules, and error handling.

Is there any extra Lonti cost to integrate Nearmap with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Nearmap. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Nearmap, cloud infrastructure, storage, or other third-party systems depending on subscriptions, usage, and deployment model.

Which Nearmap integration methods should an enterprise use?

REST APIs are the primary confirmed method for imagery, metadata, and coverage. Supported Nearmap products may also provide tile services or OGC-style map services such as WMS or WMTS. Image and tile retrieval is available in a limited, service-dependent form. GraphQL and SOAP APIs were not confirmed, and direct database access is not supported.

Does Nearmap provide webhooks or real-time events for new imagery?

A general Nearmap webhook or outbound callback framework was not confirmed. Integrations should not assume that every new image capture or coverage change generates an event. For monitoring, Martini can run scheduled workflows that query coverage or metadata endpoints and compare results with stored state.

How does synchronization with Nearmap work?

Synchronization is typically on demand or scheduled. Martini queries configured regions or areas of interest, maps coverage and imagery metadata to a canonical model, compares stable identifiers and timestamps with persisted state, and writes only new or changed results. The design should account for late-arriving metadata, no-coverage responses, pagination or response-size limits, and duplicate prevention.

How does Martini handle Nearmap errors, retries, and duplicate requests?

Martini can validate geographic parameters before making a request, classify authentication, entitlement, quota, no-coverage, malformed-response, and transient service errors separately, and retry appropriate temporary failures with bounded backoff. Stable location, capture, product, and request identifiers can support idempotency. Large or binary responses should also be governed by size, storage, and licensing rules.