Pricing that holds up at consumer scale.

InBetween is priced so a good search feature stays affordable when it succeeds: credit tiers, a free monthly allowance, and an API designed to keep the cost per decision low.

Get Started
api.inbe.us/v1/search200 OK
POST
{
"locations": [
{ "lat": 51.5072, "lon": -0.1276, "weight": 30 },
{ "lat": 51.5154, "lon": -0.1419, "weight": 40 },
{ "lat": 51.5034, "lon": -0.1195, "weight": 30 }
],
"mode": {
"mode": "POINT"
"maxDistance": 200
},
"preferences": {
"openingConditions": {
"state": "ANY"
"atTime": "2026-08-15T17:53:51.178Z"
},
"goodFor": ["family", "coffee", "date"]
"catersFilters": ["vegetarian", "glutenFree", "vegan"]
"establishmentFilters": ["restaurant"]
}
}

For teams whose location bill grows faster than their product

Cost-effective is a design decision, not a discount.

The awkward truth about most location APIs is that a successful feature becomes an expensive one. Teams end up rationing search, capping results, and designing around the bill rather than the user.

We designed InBetween around efficiency from the start. Search returns what you need to present great options; richer detail is fetched only when a user explores a specific venue. You pay for what your users actually use.

Pricing is credit-based with published tiers and a free monthly allowance, so you can forecast the bill as easily as you forecast usage.

What breaks today

  • Successful features become liabilities when every query is billed at enterprise rates.
  • Teams ration search results and filters just to keep the bill manageable.
  • Chained requests multiply the cost of answering a single user question.

What you can ship

  • Ship rich search and filtering without designing around the bill.
  • Forecast location costs as confidently as you forecast usage.
  • Replace a stack of billed calls with one request per decision.

How it works for you

  1. 01

    Build on the free allowance

    Every account includes free monthly credit, enough to prototype seriously and run early production traffic.

  2. 02

    Keep the cost per decision low

    One search request replaces the chain of geocoding, places, and detail calls you would otherwise pay for separately.

  3. 03

    Forecast with published tiers

    Credit tiers are public and predictable. No usage cliffs, no surprise invoices.

How we compare to other Places APIs

We find the right place for everyone, not just a pin on a map.

Traditional place APIs are designed to return place records. InBe is designed to resolve real decisions: where should these people meet, given everyone's needs, preferences and the experience they want?

Find and rank restaurants, bars and cafés around the people, preferences and experience that matter. From dietary and accessibility requirements to vibe, menu items and much more.

  • Preferences at the core

    Search across dietary needs, accessibility, atmosphere, vibe, menu items and other meaningful preferences, not just category.

  • Built for more than one person

    Bring multiple people's locations, and requirements, into one search and rank places for the group. No manual comparison or lowest-common-denominator filtering.

  • Optimised for an experience

    InBe helps products answer 'Where should we go?' rather than merely returning nearby records or pins.

Illustrative scenario: When preferences, access and vibe all matter

Four people are meeting for dinner. One is vegan, one needs step-free access, one wants somewhere quiet enough to talk and another needs a stiff drink. All within a practical journey for the group.

Conventional Places APIs

Conventional Places API

In progress

£0.00/1k · 250ms

  1. 250ms

    Identify the best location for the group

  2. 30ms

    Search by category at that location and receive 20 candidates

  3. 115ms · £0.005

    Receive 20 locations in that category

  4. 110ms · £0.01

    Request additional place details

  5. 80ms

    Identify relevant places

  6. 1800ms · £0.10

    Source missing menu, dietary or accessibility data

  7. 80ms

    Build custom preference and group-ranking logic

  8. 100ms

    Present options and ask users to compare them

More requests, more integration work and more decisions left to the user.

InBe

Building with InBe

In progress

£0.00/1k · 30ms

  1. 30ms

    Send the participants locations and preferences

  2. 175ms · £0.005

    Receive a ranked shortlist of 20 suitable places

  3. 110ms · £0.001

    Enrich only the places the user wants to explore

Fewer unnecessary calls, less custom logic and a faster route to a confident decision.

Conventional outcome

20 locations in the area

Nearby category matches. Preference fit and ranking still sit with you.

Total time
2,565ms

Sum of illustrative step latencies for one cycle

Cost per 1k
£115.00/1k

Illustrative list-price usage across 1,000 runs

Steps to a shortlist
8

Integration and request steps in the conventional path

Decision state
User still compares

Shortlist quality depends on filters you build and data you chase.

InBe outcome

20 perfect locations

Ranked shortlist around the group’s preferences, access needs and vibe.

Total time
315ms

Sum of illustrative step latencies for one cycle

Cost per 1k
£6.00/1k

Illustrative list-price usage across 1,000 runs

Steps to a shortlist
3

Core API actions in the InBe path

Decision state
Decision-ready shortlist

Enrich only the places people actually want to open.

About 8.1× faster and 19.2× lower cost per 1k runs in this scenario.

Capability at a glance

How a general-purpose Places API alternative compares with InBe's preference-aware restaurant recommendation API.

Strong fit / includedVaries by providerOften needs extra work

Find nearby places

Conventional Places APIs
Core focus
InBe
Included

Search around advanced preferences

Conventional Places APIs
Often requires extra data
InBe
Built in

Reconcile multiple people's needs

Conventional Places APIs
Usually requires custom logic
InBe
Designed for this

Rank places for a shared experience

Conventional Places APIs
Usually requires custom logic
InBe
Built in

Capabilities and commercial terms vary between providers. This comparison describes the typical difference between a general-purpose Places API and InBe's preference-aware venue discovery API.

The cheapest place record is not always the cheapest user experience.

InBe is not trying to win a commodity race for the cheapest raw place record. It's designed to reduce the total cost of reaching a useful answer. Better matching at the start can mean fewer calls, less scraping, less data reconciliation and less product logic to maintain.

Instead of paying to retrieve a pile of possibilities, InBe produces a ranked shortlist around what everyone actually needs. It reduces the need to depend on scraped, fragmented, old, or difficult-to-maintain data sources.

Fedor, CTO, InBe
Fedor SulitskiyCTO, InBe

Every venue. Every detail.

Precision metadata for apps that help people meet, eat and drink.

Venue intelligence

Ultra detailed venue data

Get detailed information about venues, including menus, pricing, ambiance, and more.
Smart matching

Preference driven

Wow your customers with recommendations and information tailored for them.
Multi-location search

Tools for multiple locations. Find restaurants, bars and cafés based on multiple sets of preferences and locations.

In-app experience

Loyal to you

Keep users inside your app by giving them the info they need to make decisions.
Decision support

Built for decision-making

A suite of tools designed to enable you to answer customer needs directly.

Pricing built for scale

Build the search feature you actually want to ship.

Open up a new world for your users with InBe's preference-aware venue discovery—built for group venue matching, dietary search, and ranked shortlists.

No card required. Full core API access.

Start building for freeSee pricing & migration

Keep exploring

Questions teams ask

Built for developers who connect people to places

Start buildingExplore the API

Connecting users to real-world places shouldn’t mean stitching geocoding, routing, Places search, and ranking yourself. One preference-aware search replaces the pipeline.

api.inbe.us/v1/search200 OK
POST
{
"locations": [
{ "lat": 51.523, "lon": -0.158, "label": "Alex" },
{ "lat": 51.493, "lon": -0.098, "label": "Sam" }
],
"mode": { "mode": "POINT", "maxDistance": 750 },
"preferences": {
"goodFor": ["date", "cocktails", "conversation"],
"catersFilters": ["vegetarian"],
"establishmentFilters": ["servesCocktails"]
}
}
response
{
"centerPoint": { "Lat": 51.508, "Lon": -0.128 },
"radius": 750,
"establishments": [
{
"displayName": "The Lantern Room",
"distanceMeters": 142,
"matchScore": { "total": 0.94 }
},
{
"displayName": "Barrio Soho",
"distanceMeters": 186,
"matchScore": { "total": 0.91 }
}
]
}

Fair middlegrounds

Multi-person locations in one call; we balance travel so you don’t build routing yourself.

Preferences that actually match

Dietary, vibe, good-for, and constraints as first-class inputs, not post-filters on pins.

Pay for the hard parts

Core search and enriched place data stay cheap; you pay where decision intelligence earns its keep.

Tools for user decisions

Ranked shortlists and experience-ready answers so your product keeps users in-flow, not off to a map.

Illustrative scenario

0ms

Ranked shortlist in one call

Preference-aware search returns a decision-ready shortlist without stacking Places, routing, and enrichment calls.

~15× faster vs multi-call pipelinesNot a live benchmark
RESTWorks with any stack
curl -X POST https://api.inbe.us/v1/search \
  -H "API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "locations": [
      { "lat": 51.523, "lon": -0.158, "label": "Alex" },
      { "lat": 51.493, "lon": -0.098, "label": "Sam" }
    ],
    "mode": { "mode": "POINT", "maxDistance": 750 },
    "preferences": {
      "goodFor": ["date", "cocktails", "conversation"],
      "catersFilters": ["vegetarian"],
      "establishmentFilters": ["servesCocktails"]
    }
  }'
Full examples in docs

Start in minutes with the knolage you can scale without stress.

Generous free usage to evaluate, startup credits to grow, and a migration path when you are ready to switch from stacked Places pipelines.

Start in minutes

No sales call. Sign in, grab a key, and ship a first search.

Start building

Build — free forever

£10 of usage every month, full core API, no card required.

See Build plan

InBe for Startups

£2,500 usage credit, Grow-level features, and onboarding support.

Startup programme

Switch with confidence

Migration credits from £500, dual-running help, and high-spend matched offers.

Migration programme