DEV Community: Enrique Uribe

I Got the Adidas World Cup Ball Collection for My Birthday, So I Built a Digital Museum for It

Enrique Uribe — Tue, 16 Jun 2026 15:00:25 +0000

For my birthday, I got the Adidas FIFA World Cup ball collection.

Fifteen mini balls. Fifteen tournaments. A shelf full of football history.

The soccer lover in me loved it immediately. The developer in me had a different reaction:

What if each physical ball could unlock its own digital museum page?

So over the weekend I built World Cup Ball Scanner: a browser-based museum for the collection. You can point your phone camera at a ball, let the app read the printed name, and jump into that tournament's story, stats, legends, and highlight video.

Live demo: https://world-cup-visions.vercel.app
GitHub repo: https://github.com/UribeJr/world-cup-visions

What I built

The app turns a physical collection into an interactive exhibit:

Camera scanner: reads the printed ball name with in-browser OCR.
3D gallery: a WebGL sphere of every Adidas World Cup match ball from 1970 to 2026.
Tournament pages: swipeable detail pages with host, champion, final score, attendance, legends, fun facts, and ball design history.
Highlight videos: each ball can play an owner-supplied tournament clip.
No backend: static React app, self-hosted OCR assets, no accounts, no analytics.

The goal was not just "make a database of balls." I wanted it to feel like walking up to a museum placard, except the placard reacts to the physical object in your hand.

▶ Try the live demo →

The product idea

I kept coming back to one simple user flow:

Pick up a ball -> scan it -> unlock the year.

That gave the project a clear shape. The app did not need user accounts, comments, admin dashboards, or a content management system. It needed to answer a very specific moment:

"I have this ball in my hand. What happened at that World Cup?"

So every screen is built around that.

The home screen pushes you toward scanning or browsing. The gallery gives you a visual way to explore the full collection. The detail pages give each tournament room to breathe.

How the scanner works

The scanner uses Tesseract.js, running fully in the browser.

The flow is:

Open the camera with getUserMedia.
Show a framing guide so the printed ball name sits in a predictable area.
Crop the frame to that guide before OCR.
Normalize OCR text: uppercase, strip diacritics, collapse whitespace.
Match against ball keywords with priority and light fuzzy matching.

The keyword priority matters more than I expected.

For example, TELSTAR is ambiguous. There is the 1970 Telstar, the 1974 Telstar Durlast, and the 2018 Telstar 18. If OCR only sees TELSTAR, the app should not confidently guess the wrong one.

So the matcher checks more specific phrases first:

TELSTAR 18
DURLAST
then bare TELSTAR

If a result is genuinely ambiguous, the app asks the user instead of pretending to know.

That was a good reminder: for physical-world software, "I don't know, help me choose" can be better UX than a false positive.

The 3D gallery

The gallery was the part I wanted to feel special.

I could have made a grid of cards, and the app would have worked. But a grid did not feel like a collection. It felt like a catalog.

So I built a WebGL sphere gallery with Three.js and GSAP. The cards wrap around the viewport, you can drag to rotate, and selecting a ball transitions into the detail page.

There is also a list fallback for reduced motion or browsers without WebGL support, because a fun visual should not block the core experience.

Making the tournament pages feel like exhibits

Each ball page combines two kinds of content:

Structured data: host, winner, runner-up, final score, teams, matches, goals, attendance.
Authored exhibit text: ball design, material, historical context, legends, memorable moments, and fun facts.

For example:

Jabulani 2010 is not just "Spain won." It is the first World Cup in Africa, the vuvuzela soundtrack, Iniesta's extra-time winner, and one of the most controversial balls ever made.
Brazuca 2014 is Germany's fourth title, Brazil's 7-1 trauma, and the ball that restored confidence after Jabulani's aerodynamics controversy.
Trionda 2026 is the upcoming expanded tournament across Canada, Mexico, and the United States.

The app is basically a little sports-history layer wrapped around a physical collection.

Built with

The stack:

Vite + React + TypeScript
react-router
Tesseract.js for browser OCR
Three.js for the gallery scene
GSAP for gallery/hero motion
Vitest for matcher and data tests
Vercel for hosting

The repo is public here:

https://github.com/UribeJr/world-cup-visions

Where AI helped

I used Cursor and AI assistance throughout the build, but I tried to keep it as a collaborator rather than the driver.

The useful parts were:

scaffolding boring glue code faster;
refactoring matcher logic and tests;
debugging Vercel deployment issues;
polishing the README and public repo;
checking edge cases I might have missed.

The parts I still had to own were the product decisions:

what the museum should feel like;
when to scan vs browse;
how much motion was too much;
what to cut so it stayed a weekend project;
how to connect the physical birthday gift to a digital experience.

That balance felt right. AI helped me move faster, but the point of the project was still personal.

What I would improve next

If I keep working on it, I would like to:

tune OCR keywords after testing each physical ball in different lighting;
add a more polished scan success animation;
add more behind-the-scenes stories for each tournament.

Final thought

This started as a birthday gift sitting on a shelf.

By Sunday night, it had become a tiny browser museum: part scanner, part gallery, part football-history rabbit hole.

That is my favorite kind of weekend project: personal enough to care about, technical enough to learn from, and small enough to actually finish.

If you have a minute, try it here:

https://world-cup-visions.vercel.app

https://github.com/UribeJr/world-cup-visions

What physical collection would you digitize this way?

AdblockNot - The Adblocker you've never wanted.

Enrique Uribe — Sat, 11 Apr 2026 22:13:14 +0000

This is a submission for the DEV April Fools Challenge

Adblock Not

Have you ever sat there watching a youtube ad and said "dang, I just wish there were more ads?" Welcome to AdblockNot!

What I Built

I built Adblock Not, the ad blocker you've never wanted.

Most ad blockers try to make the web less annoying. Adblock Not takes the opposite approach. It sees your desire for an ad-free experience and responds with the worst possible product decision: before it blocks ads, it makes you watch one.

Not a skippable one, either.

To make this bad idea feel more official, I wrapped the whole thing in a fake early-2000s cable/satellite interface. The overlay looks like a retro TV guide, the ads are presented like channels, and if you do not like the current ad, you can always change the channel to a different ad.

I also wanted it to tap into a very specific kind of commercial nostalgia: the era of weird infomercials, overdramatic voiceovers, late-night paid programming, and commercials you did not exactly love, but somehow still remember forever.

That is the entire value proposition:

it is an ad blocker built on a terrible premise
it treats ad blocking like premium content authorization
it adds friction where absolutely none was needed
it is less a utility and more a hostage negotiation with nostalgic television design

The current lineup includes multiple gloriously inconvenient commercials, including Fushigi, Education Connection, Nike Football, Sears, and Zoobooks.

So yes: I made software whose core feature is disrespecting your time in a more organized and stylish way.

Demo

Code

UribeJr / adblocknot

Adblock Not

Adblock Not is the ad blocker you've never wanted.

It is a joke Chrome MV3 extension built around a deliberately terrible idea: before it blocks ads, it makes you watch an ad. To make the experience feel more official, the whole gate is wrapped in a retro early-2000s TV interface with channel switching, a fake guide, and a lineup of bundled commercials.

This is not a serious ad blocker. It is an anti-product with excellent commitment to the bit.

What It Does

Detects when a page should show the Adblock Not gate.
Opens a fullscreen retro TV-style overlay before ad blocking is allowed.
Makes you watch one of several bundled ad videos to completion, or wait through a fallback timer if playback fails.
Lets you "change the channel" to a different ad, which is obviously not real relief.
Includes a retro guide UI so you can manually pick…

View on GitHub

How I Built It

Adblock Not is a Chrome Manifest V3 extension built with plain JavaScript, HTML, and CSS.

The basic idea was simple: if an ad blocker is supposed to remove interruptions, I wanted to build one that introduces a brand new interruption first.

The extension injects a fullscreen content-script overlay onto pages, then uses a background service worker to track whether the user has satisfied the completely unnecessary ad-watching requirement.

Main pieces:

manifest.json wires up the MV3 extension, content script, service worker, and bundled media assets.
src/content/gate-overlay.js renders the fake TV UI, loads the bundled ad videos, handles channel switching, opens the guide, and controls the unlock flow.
src/content/gate-overlay.css gives the whole experience the retro cable-box look.
src/background/service-worker.js stores unlock state and decides whether the gate should appear.

Some of my favorite details:

The entire joke works because the product logic is coherent. Every part of it is committed to making ad blocking slightly more annoying.
The guide UI is based on old cable/satellite channel guides because that era already felt one tiny step away from self-parody.
The bundled ads are part of the joke, but they are also part of the nostalgia. They come from that very specific "how is this on television again?" era of commercials that burned themselves into your brain.
The video player uses custom controls to keep the fake-TV vibe intact.
"Change the channel" is my favorite feature because it sounds like a mercy feature, but it is actually just a different route to the same suffering.

Technically, it was also a fun constraint: make something that is dumb on purpose, but polished enough that the joke lands immediately.

Prize Category

Primary category:

Community Favorite

Why:

I built this as a pure anti-product. The concept is immediate, the joke is obvious, and the whole thing is committed to the bit: an ad blocker that forces you to watch ads before it helps you avoid ads.

Alternate category I could also argue for:

Best Ode to Larry Masinter

Why:

The project is built in the spirit of lovingly useless internet/software humor. It is not practical, it is not responsible, and it is absolutely committed to the bit.

Good luck to all the winners! This was fun to dive into as a pretty 'basic' notion user. MCP really helped learn the ins and outs of what notion can provide.

Enrique Uribe — Wed, 01 Apr 2026 18:24:29 +0000

Notion MCP Challenge Submission 🧠

Enrique Uribe

Mar 27

I built an AI behavioral Brain with Notion MCP

#devchallenge #notionchallenge #mcp #ai

5 min read

[Boost]

Enrique Uribe — Mon, 30 Mar 2026 15:20:22 +0000

Notion MCP Challenge Submission 🧠

Enrique Uribe

Mar 27

I built an AI behavioral Brain with Notion MCP

#devchallenge #notionchallenge #mcp #ai

5 min read

[Boost]

Enrique Uribe — Sat, 28 Mar 2026 14:01:25 +0000

Notion MCP Challenge Submission 🧠

Enrique Uribe

Mar 27

I built an AI E-Commerce Brain with Notion MCP

#devchallenge #notionchallenge #mcp #ai

5 min read

I built an AI behavioral Brain with Notion MCP

Enrique Uribe — Fri, 27 Mar 2026 20:30:12 +0000

This is a submission for the Notion MCP Challenge

What I Built

I built an AI e-commerce brain for a Shopify storefront using Notion MCP as the behavior control layer.

On the surface, it looks like one shopping assistant. Under the hood, it behaves more like a network of specialists:

a training bag specialist
a gloves and wraps specialist
a cart review specialist
an order history specialist
an add-to-cart specialist

The architecture is split intentionally.

The app keeps ownership of:

intent classification and routing
Shopify integration
ranking and filtering
session and conversation state
validation and fallback logic
performance and caching

Notion owns the behavior layer for each intent:

tone and voice
intent instructions
recommendation strategy
questions to ask
do / do not rules
example responses
behavior notes
synced intent synonyms

That means I can change how the AI behaves per scenario without rewriting prompts throughout the codebase.

Instead of one generic chatbot, I now have a commerce system made up of specialist branches like:

search_training_bags
search_gloves_wraps
cart_review
orders_selection
order_detail

This makes the behavior visible, editable, and operational.

I also built a publish model so Notion is safe to use in production:

Edit behavior in Notion
Click Sync from Notion
Publish the behavior into the app
Run the storefront from the published config locally for fast runtime performance

I also built the reverse flow:

Sync to Notion

So the app can push its current behavior definitions back into the Notion database.

This turned Notion from a documentation layer into a real control plane for the AI.

Video Demo

In the demo, I walk through:

the Notion behavior control panel
the specialist intent rows
the sync workflow
changing behavior in Notion and seeing the storefront assistant respond differently
category-specific shopping flows like training bags and gloves/wraps

Show us the code

Parse Notion rows into behavior config

This is the layer that turns a Notion database row into a specialist behavior object the app can use at runtime.

function parseNotionBehaviorRow(page) {
  const properties = page?.properties || {};
  const intent = pickProperty(properties, ['intent', 'name', 'title']);
  const key = normalizeIntentKey(intent);
  if (!key) return null;

  const enabledRaw = pickProperty(properties, ['enabled', 'active']);
  const enabled = enabledRaw ? enabledRaw === 'true' : true;

  return {
    key,
    enabled,
    intentSynonyms: pickProperty(properties, ['intent_synonyms', 'synonyms', 'trigger_phrases']),
    toneVoice: pickProperty(properties, ['tone_voice', 'tone', 'voice']),
    intentInstructions: pickProperty(properties, ['intent_instructions', 'instructions']),
    questionsToAsk: pickProperty(properties, ['questions_to_ask', 'questions']),
    recommendationStrategy: pickProperty(properties, ['product_recommendation_strategy', 'recommendation_strategy']),
    doRules: pickProperty(properties, ['do', 'do_rules']),
    doNotRules: pickProperty(properties, ['do_not', 'do_not_rules']),
    upsellCrossSellStrategy: pickProperty(properties, ['upsell_cross_sell_strategy', 'upsell_strategy', 'cross_sell_strategy']),
    exampleResponses: pickProperty(properties, ['example_responses', 'examples']),
    behaviorNotes: pickProperty(properties, ['behavior_notes', 'notes']),
  };
}

Sync behavior from Notion into the app

This is the publish step. It pulls the latest behavior definitions from Notion and stores a published config in the app for fast local runtime use.

export async function syncChatBehaviorFromNotion(shop) {
  const config = await fetchNotionBehaviorDatabase();
  const publishedConfig = normalizePublishedBehaviorConfig({
    ...config,
    source: 'published_notion',
    publishedAt: new Date().toISOString(),
  });

  await updateSettings(shop, {
    behaviorConfigJson: JSON.stringify(publishedConfig),
    behaviorConfigSource: publishedConfig.source,
    behaviorSyncedAt: new Date(),
  });

  behaviorCache = {
    shop,
    config: publishedConfig,
    expiresAt: Date.now() + (Number(process.env.NOTION_BEHAVIOR_CACHE_MS || DEFAULT_CACHE_MS) || DEFAULT_CACHE_MS),
  };

  return publishedConfig;
}

Sync behavior back to Notion

This is the reverse direction. It pushes app-side behavior definitions back into the Notion control panel so the system stays visible and editable.

export async function syncChatBehaviorToNotion(shop) {
  const token = sanitizeText(process.env.NOTION_API_TOKEN);
  const databaseId = sanitizeText(process.env.NOTION_BEHAVIOR_DATABASE_ID);
  if (!token || !databaseId) {
    throw new Error('Missing NOTION_API_TOKEN or NOTION_BEHAVIOR_DATABASE_ID.');
  }

  const settings = shop ? await getSettings(shop) : null;
  const publishedConfig = parseBehaviorConfigJson(settings?.behaviorConfigJson) || cloneDefaultConfig();
  const effectiveConfig = normalizePublishedBehaviorConfig({
    ...publishedConfig,
    source: publishedConfig?.source || 'published',
  });

  const existingRows = await queryNotionBehaviorRows(token, databaseId);
  const rowMap = new Map();

  for (const row of existingRows) {
    const parsed = parseNotionBehaviorRow(row);
    if (!parsed?.key) continue;
    rowMap.set(parsed.key, row.id);
  }

  const intents = Object.entries(effectiveConfig.intents || {});
  for (const [intentKey, behavior] of intents) {
    const mergedBehavior = {
      ...(effectiveConfig.global || {}),
      ...(behavior || {}),
    };

    const properties = buildNotionBehaviorProperties(intentKey, mergedBehavior);
    const existingPageId = rowMap.get(intentKey);

    if (existingPageId) {
      await updateNotionBehaviorPage(token, existingPageId, properties);
    } else {
      await createNotionBehaviorPage(token, databaseId, properties);
    }
  }

  return {
    pushedAt: new Date().toISOString(),
    intentCount: intents.length,
  };
}

Runtime behavior loading in storefront chat

This is where the storefront chat loads the published behavior config for the active shop before generating a response.

const behaviorConfig = await getChatBehaviorConfig(shopDomain || session?.shop || '');

Then later, the response generator uses the active specialist behavior:

async function generateAssistantCopy({
  query,
  items,
  allowFollowups,
  policyAnswer,
  apiKey,
  chatHistory = [],
  behaviorConfig,
  behaviorIntent = 'search'
}) {
  // ... build shortlist and conversation context ...

  const recommendationInstruction =
    behaviorIntent === 'search_training_bags'
      ? trainingBagFollowupInstruction
      : standardFollowupInstruction;

  // behaviorConfig + behaviorIntent shape the final response
}

Admin actions for the two sync buttons

This is the UI-facing action layer that powers Sync From Notion and Sync To Notion.

export const action = async ({ request }) => {
  const { session } = await authenticate.admin(request);
  const formData = await request.formData();
  const actionType = formData.get("action");

  if (actionType === "sync_behavior_to_notion") {
    const result = await syncChatBehaviorToNotion(session.shop);
    return json({
      ok: true,
      behaviorPush: true,
      pushedAt: result?.pushedAt || new Date().toISOString(),
      message: `Behavior pushed to Notion for ${result?.intentCount || 0} intents.`,
    });
  }

  if (actionType === "sync_behavior_from_notion") {
    const config = await syncChatBehaviorFromNotion(session.shop);
    return json({
      ok: true,
      behaviorSync: true,
      source: config?.source || "published_notion",
      syncedAt: config?.publishedAt || config?.fetchedAt || new Date().toISOString(),
      message: "Behavior synced from Notion.",
    });
  }
};

How I Used Notion MCP

Notion MCP is what made this system possible in a meaningful way.

I used Notion MCP to create and operate a behavior database that acts like a control room for the storefront AI.

Each row in Notion represents an intent or a specialized branch, for example:

search
search_training_bags
search_gloves_wraps
cart_review
orders_selection
order_detail

Each row contains structured behavior fields like:

Tone Voice
Intent Synonyms
Intent Instructions
Questions To Ask
Product Recommendation Strategy
Do
Do Not
Example Responses
Behavior Notes

This let me turn Notion into an operator-facing behavior system instead of just a place to store notes.

For example:

the training bag specialist can focus on freestanding vs hanging bag decisions
the gloves and wraps specialist can focus on MMA gloves, boxing gloves, bag gloves, wraps, padding, and protection
the cart review specialist can behave more like a checkout assistant
the order specialists can stay concise and service-oriented

The important part is that Notion MCP did not just help me document the system. It helped me build the system that controls the AI behavior.

That unlocked a much stronger workflow:

identify a weak response
update the specialist behavior in Notion
sync it into the app
test it live in the storefront

That is why I think this is a strong Notion MCP use case.

I did not just connect Notion to an agent.
I used Notion MCP to build the behavior control plane for an AI commerce brain.

Cart Review Behavior:

Sale Search Behavior

The part I like most is that behavior is no longer buried in prompts or scattered across code. Notion became a real operating surface for the AI, and that made the storefront feel less like a chatbot and more like a system of specialists that can actually be tuned, tested, and improved over time.

🧠 My 2026 Shopify Stack — I Don’t Build Apps, I Build Business Solutions

Enrique Uribe — Tue, 24 Feb 2026 20:47:03 +0000

I don’t build Shopify apps for fun.

I build systems that:

Automate operations
Reduce manual work
Protect revenue
Increase AOV
Clean up messy workflows

Shopify is just the platform.

The real goal is solving business problems.

This is the stack I use every day to do that.

1️⃣ Shopify CLI — The Operational Backbone

Every solution starts here.

shopify app init
shopify app dev

That one workflow covers the things that usually break first:

OAuth
Local development
Environment wiring
Fast iteration loops

When you’re shipping revenue-impacting logic, fragile setup is a liability.

CLI keeps the foundation predictable.

2️⃣ Shopify MCP — Build Against Reality, Not Assumptions

Most bugs happen because developers assume store structure.

I don’t assume. I inspect.

Before building logic around products or metafields, I look at what actually exists:

query {
  products(first: 3) {
    edges {
      node {
        id
        title
        metafields(first: 10) {
          edges {
            node {
              namespace
              key
              type
            }
          }
        }
      }
    }
  }
}

Now I’m working with:

Real namespaces
Real types
Real data patterns

When business logic depends on structure, guessing gets expensive.

3️⃣ Admin GraphQL API — Precision Over Noise

Business solutions need precision.

Example: auto-tag high-value orders so the ops team can prioritize them.

const mutation = `
mutation AddOrderTag($id: ID!, $tags: [String!]!) {
  tagsAdd(id: $id, tags: $tags) {
    node { id }
    userErrors { field message }
  }
}
`;

const response = await admin.graphql(mutation, {
  variables: {
    id: orderId,
    tags: ["Priority"]
  }
});

const data = await response.json();

if (data.data.tagsAdd.userErrors.length > 0) {
  console.error(data.data.tagsAdd.userErrors);
}

Small example. Real impact.

GraphQL lets me:

Scope tightly
Avoid overfetching
Control exactly what the system does

When thousands of events are flowing through your app, precision matters.

4️⃣ Webhooks — Event-Driven Automation

I don’t poll.

I react.

Most business automation is event-based:

Orders
Product updates
Customer creation
App uninstall events

Minimal webhook skeleton:

import { authenticate } from "../shopify.server";

export const action = async ({ request }) => {
  const { topic, payload, shop } = await authenticate.webhook(request);

  if (topic === "ORDERS_CREATE") {
    console.log(`New order from ${shop}`);

    // Example: run automation logic here
    // await handleOrderAutomation(payload);
  }

  return new Response(null, { status: 200 });
};

This is where Shopify turns into a business operating system.

The store moves.

Your system responds.

5️⃣ Tunneling — Clean Install & Testing Cycles

Business solutions often depend on:

OAuth behaving correctly
Webhooks firing reliably
Installation flow being clean

shopify app dev handles tunneling seamlessly.

That means I can:

Reinstall repeatedly
Test webhook flows safely
Simulate real store conditions

Stability during development prevents chaos in production.

6️⃣ DevTools — Because Business Owners Notice Speed

If your embedded app slows down the Shopify admin, it won’t survive.

I constantly inspect:

Bundle size
Network waterfalls
Blocking scripts
Unnecessary re-renders

Merchants don’t care how elegant your architecture is.

They care if it feels fast.

Business impact > technical elegance.

The Real Difference

Anyone can build features.

Not everyone builds solutions.

The difference is:

Thinking in workflows, not endpoints
Designing event-driven systems
Validating store structure before writing logic
Treating revenue-impacting code with discipline
Building for scale from day one

Shopify is just the canvas.

The real work is understanding the business behind it.

Closing Thought

In 2026, Shopify development isn’t about who writes the cleanest code.

It’s about who designs systems that:

Survive scale
Protect revenue
Reduce operational friction
Make merchants’ lives easier

That’s the stack I build with.

If you’re building on Shopify — are you building features, or building systems?

Using banner bear’s AI image creation to automate designer workflows. Check it out!

Enrique Uribe — Sun, 15 Feb 2026 00:33:53 +0000

🚀 Automating Email Image Requests with Asana + Zapier + BannerBear

Enrique Uribe ・ Feb 12

#automation #nocode #api #productivity

🚀 Automating Email Image Requests with Asana + Zapier + BannerBear

Enrique Uribe — Thu, 12 Feb 2026 17:37:31 +0000

Some companies operate multiple sub-brands under one marketing department.

Each brand has:

Its own identity
Its own templates
Its own dedicated graphic designers

But most email campaigns follow repeatable patterns — flash sales, limited-time offers, announcements.

Instead of having designers rebuild the same promo layouts every time, this system automates the repetitive production work while preserving brand control.

Built with:

Asana → request form intake
Zapier → routing + logic
BannerBear → image rendering

🧠 The Goal

This wasn’t about replacing designers.

It was about removing repetitive promo production so designers can focus on:

Campaign concepts
Brand evolution
High-impact creative
Strategic visual storytelling

Designers build the master templates once.

Automation handles recurring production.

That shift alone makes a huge difference.

🏗 How It Works

Here’s the full workflow from request to finished asset:

1️⃣ Marketing Submits a Form

The marketing team fills out a structured form inside Asana.

That form automatically creates a task in the Email Image Requests project with:

Division
Template type
Promo details
Copy
Any needed assets

Everything starts from one intake system.

2️⃣ Designer Reviews the Request

Each brand has a dedicated designer.

The assigned designer reviews the task and ensures:

Copy is correct
Template selection makes sense
Assets are attached
Everything is ready

When it’s approved, the designer moves the task to:

“Ready to Render”

3️⃣ Moving to “Ready to Render” Triggers the Zap

That section change triggers the automation.

Zapier then:

Pulls all task data
Checks the Division
Checks the Template type
Maps the task data to the correct BannerBear template

4️⃣ BannerBear Generates the Image

Zapier sends the mapped data to BannerBear.

BannerBear renders the image based on the correct brand template.

No manual design work required.

{
  "template": "V32jY9bBM6l0DBGWrl",
  "modifications": [
    {
      "name": "BG_COLOR",
      "color": null
    },
    {
      "name": "TXT_HEADLINE",
      "text": "You can change this text",
      "color": null,
      "background": null
    },
    {
      "name": "CTA_COLOR",
      "color": null
    },
    {
      "name": "TXT_CTA",
      "text": "You can change this text",
      "color": null,
      "background": null
    },
    {
      "name": "TXT_BODY",
      "text": "You can change this text",
      "color": null,
      "background": null
    },
    {
      "name": "IMG_FEATURED",
      "image_url": "https://cdn.bannerbear.com/sample_images/welcome_bear_photo.jpg"
    },
    {
      "name": "TXT_SUBHEAD",
      "text": "You can change this text",
      "color": null,
      "background": null
    },
    {
      "name": "TXT_LEGAL",
      "text": "You can change this text",
      "color": null,
      "background": null
    }
  ],
  "webhook_url": null,
  "transparent": false,
  "metadata": null
}