AdminConsole
Tutorials/Beginner
Beginner10 minWeb

Put your first Mappls map on the web

Create a key, restrict it to localhost, load Web Maps JS, and add a marker.

By the endA responsive map with a styled point of interest.
Real-world scenario

Build against an explicit contract

A property-search page needs one responsive map that remains usable with keyboard navigation and slow networks.

A Mappls developer projectA restricted Web applicationFixture data with no production credentialsA request, aggregate, or correlation ID strategy
Step 1

Define the user and system contract

A property-search page needs one responsive map that remains usable with keyboard navigation and slow networks. Record the region, data freshness, latency budget, privacy purpose, credential owner, and fallback before choosing an SDK or endpoint.

Step 2

Create a browser-owned application

Create a development web application, restrict its public key to the exact localhost origin, and keep server credentials out of HTML and JavaScript.

Maps · SDK or product slice
<!doctype html>
<html>
  <head>
    <script src="https://sdk.mappls.com/map/sdk/web?v=3.0&access_token=YOUR_STATIC_KEY"></script>
    <style>html, body, #map { height: 100%; margin: 0; }</style>
  </head>
  <body>
    <div id="map"></div>
    <script>
      const map = new mappls.Map("map", {
        center: { lat: 28.612964, lng: 77.229463 },
        zoom: 12
      });
    </script>
  </body>
</html>
Step 3

Mount and own the map lifecycle

Load Web Maps JS once, give the container an explicit height, create the map after the DOM exists, and remove listeners when the page unmounts.

Step 4

Add one stable place

Represent the point with a durable Mappls Pin or business ID, move the camera deliberately, and mirror the selected feature in accessible text outside the canvas.

Step 5

Prove the production behavior

Automate the happy path and every named failure. The release is ready only when the map renders at mobile and desktop widths; keyboard users can reach the selected place; a blocked sdk produces a useful fallback. Capture provider request identity without logging credentials or unnecessary precise location.

Recovery design

Failure modes you must exercise

invalid or origin-restricted key

Fail fast with a typed, user-safe outcome and preserve the original request identity.

SDK load timeout

Keep the last verified state, mark freshness honestly, and retry only within the documented idempotency boundary.

zero-size or detached container

Reconcile durable local and provider evidence before declaring success or issuing a compensating command.

Never turn uncertainty into success

Timeout after a stateful command is an unknown outcome. Query by provider/idempotency identity or wait for authoritative events; do not blindly retry a new command.

Acceptance criteria

Definition of done

the map renders at mobile and desktop widthskeyboard users can reach the selected placea blocked SDK produces a useful fallback

Web production checks

Origin restrictions include every deployed hostnameMap lifecycle follows the framework lifecycleLarge datasets are tiled, clustered, or progressively loadedKeyboard, touch, reduced-motion, and failure states are tested
Grounded implementation

Continue from source, contracts, and a full app

These links resolve to repository-derived evidence; unsupported package names and endpoints are not filled in from guesswork.

Tutorial complete

Run it, break it, then observe it

Start with fixture credentials, execute the failure plan, and use request logs, usage, webhook evidence, and operational metrics before promoting traffic.