How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Event dispatch — Automation Mastery

Day 5 · ~12 min●

A webhook endpoint usually receives many event types. payment.captured, payment.refunded, payment.disputed — your handler reacts differently to each. The dispatch is a function-of-event-type.

Two idiomatic shapes:

python

# Shape A — if/elif chain (3-4 branches max)
def handle(event):
    t = event.get("type")
    if t == "item.created":
        return handle_created(event)
    elif t == "item.updated":
        return handle_updated(event)
    elif t == "item.deleted":
        return handle_deleted(event)
    else:
        return None

python

# Shape B — dispatch table (4+ branches, scales cleanly)
def handle(event):
    handlers = {
        "item.created": handle_created,
        "item.updated": handle_updated,
        "item.deleted": handle_deleted,
    }
    fn = handlers.get(event.get("type"))
    if fn:
        return fn(event)
    return None

Why a separate handler per type? Couldn't I just if/elif inside one function?

You can. The split helps when:

Each handler is more than 5-10 lines
Different handlers need different state, logging, or error-handling shapes
You want each handler unit-testable in isolation

For a 3-line response per event type, a single function with if/elif is fine. The split is a tool you reach for when the handler grows.

What about unknown event types?

Always have a default branch. Either ignore-and-log or raise. "Unknown event type" is something you want to see in your logs — a provider might add a new event type and you'd otherwise miss it.

Event dispatch — choose handler by type

The pattern

python

def handle_event(payload):
    event = payload.get("event", {})
    event_type = event.get("type")

    if event_type == "item.created":
        return on_created(event)
    elif event_type == "item.updated":
        return on_updated(event)
    elif event_type == "item.deleted":
        return on_deleted(event)
    else:
        print(f"unhandled event type: {event_type}")
        return None

Three consistent steps:

Extract the type with .get
Branch to the right handler
Default branch for unknown types — log it, don't ignore silently

When to switch from `if/elif` to a dispatch table

At 4+ branches, the dispatch table is clearer:

python

HANDLERS = {
    "item.created": on_created,
    "item.updated": on_updated,
    "item.deleted": on_deleted,
    "item.archived": on_archived,
    "item.restored": on_restored,
}

fn = HANDLERS.get(event_type)
if fn:
    fn(event)
else:
    print(f"unhandled: {event_type}")

Benefits:

Adding a type = one new entry, no elif insertion
The set of handled types is a single readable data structure
Easy to introspect — print(HANDLERS.keys()) lists supported types

Returning early on unknown types

Providers add new event types over time. Your handler should not crash on a type it doesn't recognize. Two strategies:

Return 200 OK to the provider so they don't retry, log the unknown type, move on.
Return 200 OK but also alert internally (week 3) so you can decide whether to add the handler.

Never raise on unknown event type — providers will retry, your endpoint will get spammed, real events will queue up behind dead-letter retries.

Testing dispatch in isolation

The dispatch logic is pure: takes a parsed event, returns a result. It's the easiest piece of any webhook handler to test:

python

assert dispatch({"type": "item.created"}) == "created"
assert dispatch({"type": "item.unknown"}) is None

Unit tests on dispatch logic are cheap and catch a lot of bugs.

Day 5 · ~12 min●

A webhook endpoint usually receives many event types. payment.captured, payment.refunded, payment.disputed — your handler reacts differently to each. The dispatch is a function-of-event-type.

Two idiomatic shapes:

python

# Shape A — if/elif chain (3-4 branches max)
def handle(event):
    t = event.get("type")
    if t == "item.created":
        return handle_created(event)
    elif t == "item.updated":
        return handle_updated(event)
    elif t == "item.deleted":
        return handle_deleted(event)
    else:
        return None

python

# Shape B — dispatch table (4+ branches, scales cleanly)
def handle(event):
    handlers = {
        "item.created": handle_created,
        "item.updated": handle_updated,
        "item.deleted": handle_deleted,
    }
    fn = handlers.get(event.get("type"))
    if fn:
        return fn(event)
    return None

Why a separate handler per type? Couldn't I just if/elif inside one function?

You can. The split helps when:

Each handler is more than 5-10 lines
Different handlers need different state, logging, or error-handling shapes
You want each handler unit-testable in isolation

For a 3-line response per event type, a single function with if/elif is fine. The split is a tool you reach for when the handler grows.

What about unknown event types?

Always have a default branch. Either ignore-and-log or raise. "Unknown event type" is something you want to see in your logs — a provider might add a new event type and you'd otherwise miss it.

Event dispatch — choose handler by type

The pattern

python

def handle_event(payload):
    event = payload.get("event", {})
    event_type = event.get("type")

    if event_type == "item.created":
        return on_created(event)
    elif event_type == "item.updated":
        return on_updated(event)
    elif event_type == "item.deleted":
        return on_deleted(event)
    else:
        print(f"unhandled event type: {event_type}")
        return None

Three consistent steps:

Extract the type with .get
Branch to the right handler
Default branch for unknown types — log it, don't ignore silently

When to switch from `if/elif` to a dispatch table

At 4+ branches, the dispatch table is clearer:

python

HANDLERS = {
    "item.created": on_created,
    "item.updated": on_updated,
    "item.deleted": on_deleted,
    "item.archived": on_archived,
    "item.restored": on_restored,
}

fn = HANDLERS.get(event_type)
if fn:
    fn(event)
else:
    print(f"unhandled: {event_type}")

Benefits:

Adding a type = one new entry, no elif insertion
The set of handled types is a single readable data structure
Easy to introspect — print(HANDLERS.keys()) lists supported types

Returning early on unknown types

Providers add new event types over time. Your handler should not crash on a type it doesn't recognize. Two strategies:

Return 200 OK to the provider so they don't retry, log the unknown type, move on.
Return 200 OK but also alert internally (week 3) so you can decide whether to add the handler.

Never raise on unknown event type — providers will retry, your endpoint will get spammed, real events will queue up behind dead-letter retries.

Testing dispatch in isolation

The dispatch logic is pure: takes a parsed event, returns a result. It's the easiest piece of any webhook handler to test:

python

assert dispatch({"type": "item.created"}) == "created"
assert dispatch({"type": "item.unknown"}) is None

Unit tests on dispatch logic are cheap and catch a lot of bugs.

Event dispatch — choose handler by type

The pattern

When to switch from `if/elif` to a dispatch table

Returning early on unknown types

Testing dispatch in isolation

Event dispatch — choose handler by type

The pattern

When to switch from `if/elif` to a dispatch table

Returning early on unknown types

Testing dispatch in isolation

Event dispatch — choose handler by type

The pattern

When to switch from `if/elif` to a dispatch table

Returning early on unknown types

Testing dispatch in isolation

Sign up to practice

Event dispatch — choose handler by type

The pattern

When to switch from `if/elif` to a dispatch table

Returning early on unknown types

Testing dispatch in isolation

Sign up to practice

Event dispatch — choose handler by type

The pattern

When to switch from if/elif to a dispatch table

Returning early on unknown types

Testing dispatch in isolation

Event dispatch — choose handler by type

The pattern

When to switch from if/elif to a dispatch table

Returning early on unknown types

Testing dispatch in isolation

Event dispatch — choose handler by type

The pattern

When to switch from if/elif to a dispatch table

Returning early on unknown types

Testing dispatch in isolation

Sign up to practice

Event dispatch — choose handler by type

The pattern

When to switch from if/elif to a dispatch table

Returning early on unknown types

Testing dispatch in isolation

Sign up to practice

When to switch from `if/elif` to a dispatch table

When to switch from `if/elif` to a dispatch table

When to switch from `if/elif` to a dispatch table

When to switch from `if/elif` to a dispatch table