Interesting project. I’m curious, was this something you built for the hackathon, or is it based on an existing system you’re already using in your company?
Do I need to continue running the Neo4j instance and keep open the MCP server?
Hi, well, let's say it's both.
Original version was built over couple of weekends using Neo4j database running locally and custom pipeline with cypher and Mistral.
The most tedious task was data cleaning. Front and back total maybe 2 days.
For the hackathon:
- database migrated to the Aura cloud and reembeded with gemini-embedding (locally I use bge-m3)
- pipeline had to be rebuilt using Aura Agent.
- tuning
So, the idea was there already, I built a proof that it can work using Aura Agent.
Credits have been set for the following contributors (tagged below). Please let us know if you have not received yours via email. We still have 5 submitted projects and can’t wait to see even more!
@tchinkia1
@gundavarapuganesh
@tantk7
@gorczycapj
@RohanExploit
@strategysamuel
@epiphanyan
@dairon
@leongkwokhing
@arunmv.eh
震度 Shindo — Japan Seismic Risk Intelligence Graph
Agent Name: 震度 (Shindo) — Japan's official seismic intensity scale.
A cascading risk graph that connects earthquakes, fault zones, tsunamis, nuclear facilities, and prefectures — so an AI agent can reason over disaster chains, not just look up events.
Neo4j Competition Submission
Agent Name
震度 Shindo — named after Japan's official seismic intensity scale (JMA). Shindo measures the intensity of shaking at a specific location, not just the energy at the source. This agent reasons the same way: local impact and cascading consequences, not just raw magnitude.
What It Does
震度 Shindo is a seismic intelligence agent for Japan. The user clicks anywhere on a live SVG map to place a simulated earthquake. The agent immediately analyses the event against the graph:
-
Which fault zone ruptured, and what is its historical overdue ratio?
-
Which prefectures are in the felt zone? Which have nuclear facilities?
-
Are there historical analogs in the graph? What happened then?
-
Is tsunami risk expected given the fault type and depth?
Every claim the agent makes is anchored to a Cypher query result from the graph — no hallucination.
Beyond the map there are three analytical views:
-
EDA Charts — decade-by-decade event counts, fault zone death totals, prefecture composite risk index
-
Risk Analysis — statistical recurrence gauges: how long since each fault zone last had a major event versus its historical average interval, expressed as an overdue ratio
-
Cypher Queries — graph schema explorer with template query patterns pre-loaded
Dataset and Why a Graph Fits
Dataset: USGS Earthquake Hazards Program (~20,000 M4.0+ events, 1950–2024) + IAEA PRIS nuclear reactor registry + curated fault zone reference data + JMA prefecture data (47 prefectures with coastal classifications).
Why a graph: Japan's disasters don't happen in isolation — they cascade:
Fault rupture → Ground shaking → Tsunami generation → Prefecture inundation → Nuclear facility exposure
A CSV stores events. A graph stores the chain — and an agent can traverse it in a single query. The nuclear proximity layer is the distinguishing move. Post-Fukushima, this is the question that actually matters in Japanese disaster planning. In SQL you'd need a spatial join, a subquery, and three table hops. In Cypher:
MATCH (eq:Earthquake)-[:WITHIN_50KM_OF]->(nf:NuclearFacility)
WHERE eq.magnitude >= 6.5
RETURN eq.time, eq.magnitude, nf.name, nf.status
The 2011 Tōhoku earthquake didn't just happen — it traversed a graph:
Japan Trench ruptured
→ M9.1 earthquake struck
→ 40m tsunami generated
→ Miyagi, Iwate, Fukushima inundated
→ Fukushima Daiichi within 10km of impact
→ cascading nuclear crisis
Every link in that chain is a graph edge. The agent can trace it, explain it, and ask: which other fault zones have the same potential?
Agent in the Aura Console
Graph visualisation — full schema, all node types connected:
Agent configuration — 震度 Shindo agent wired to the Earthquake Data instance:
All nine Cypher Template tools registered on the agent:
Agent in Action
Live map — Japan with all fault zones rendered, ready to simulate:
Active simulation — epicentre placed, impact zone calculated, nuclear exposure flagged:
Agent analysis — structured response grounded in graph data:
Data Analysis Dashboard — EDA Charts: decade bar chart, fault zone deaths, prefecture risk index:
Dashboard with agent responding to event analysis alongside EDA charts:
Risk Analysis tab — statistical recurrence overview with disclaimer:
Risk Analysis — per-fault-zone gauges (Noto Peninsula, Ryukyu Trench, Sagami Trough):
Cypher Queries tab — graph schema explorer with template patterns:
Cascade trace query executed — fault zone through to nuclear facility:
Live Agent
Live app: shindo-earthquake-graph.pages.dev
GitHub: Dean-Foulds/shindo-earthquake-graph
What Is the Shindo Scale?
震度 (shindo) is Japan's official seismic intensity scale, published by the Japan Meteorological Agency (JMA). Unlike moment magnitude (Mw), which measures energy released at the source, Shindo measures the intensity of shaking at a specific location. The same earthquake registers a different Shindo value in Tokyo versus Osaka.
| Shindo | JMA Level | Typical Effects |
|---|---|---|
| 0 | Micro | Not felt |
| 1 | Minor | Felt by still observers indoors |
| 2 | Light | Hanging objects sway noticeably |
| 3 | Weak | Dishes rattle; felt outdoors |
| 4 | Moderate | Unstable objects fall; most people frightened |
| 5 Lower | Strong | Heavy furniture moves; many seek safety |
| 5 Upper | Strong | Many people cannot move without holding on |
| 6 Lower | Very Strong | Impossible to stand; partial building collapse |
| 6 Upper | Very Strong | Cannot move at all; most unreinforced buildings collapse |
| 7 | Violent | Ground deforms; landslides; extreme tsunami risk |
This agent is named 震度 because it reasons about local impact and cascading consequences — not just raw magnitude at the source.
Graph Schema
Node Labels
| Label | Count | Key Properties |
|---|---|---|
Earthquake |
~20,000 | id, magnitude, depth_km, lat, lon, year, decade, severity, deaths, tsunami |
FaultZone |
9 | id, name, type, plates, predicted_max_mag, last_major_year |
Tsunami |
24 | id, max_height_m, source_mag, year |
Prefecture |
47 | id, name, region, lat, lon, coast, population_m |
NuclearFacility |
15 | id, name, lat, lon, reactors, status, operator |
Decade |
8 | year, label |
severity values: minor (M<4.0) · moderate (M4.0–4.9) · strong (M5.0–6.9) · major (M7.0–7.9) · catastrophic (M8.0+)
Relationship Types
| Relationship | From → To | Meaning |
|---|---|---|
ORIGINATED_ON |
Earthquake → FaultZone | Quake occurred on this fault |
TRIGGERED |
Earthquake → Tsunami | Quake caused a tsunami |
STRUCK |
Earthquake → Prefecture | Nearest affected prefecture |
INUNDATED |
Tsunami → Prefecture | Tsunami reached this coast |
UNDERLIES |
FaultZone → Prefecture | Fault runs beneath the prefecture |
CONTAINS |
Prefecture → NuclearFacility | Plant is in this prefecture |
WITHIN_50KM_OF |
Earthquake → NuclearFacility | Epicentre within 50km of plant |
BORDERS |
Prefecture → Prefecture | Geographic adjacency |
IN_DECADE |
Earthquake → Decade | Temporal grouping |
Neo4j Best Practices Used
- MERGE throughout — all load scripts are idempotent; safe to re-run without duplicates
- Constraints before data — unique constraints on
id/yearcreated first - Indexes on query hotpaths —
magnitude,year,tsunamiindexed for range scans - Vector indexes —
earthquake_embedding,fault_zone_embedding,nuclear_embedding,prefecture_embedding,tsunami_embeddingviadb.index.vector.queryNodes - Read-only guard —
cypher_read()in the API rejects any query containing write keywords before it reaches Neo4j
Agent Tools
Cypher Templates (9 registered)
| Tool | Description |
|---|---|
the_cascade_trace |
Full chain: fault zone → earthquake → tsunami → prefecture → nuclear facility |
compound_risk_corridors |
Subduction faults overlapping nuclear-hosting, Pacific-coast prefectures |
historical_analog_finder |
Past events near a given location and magnitude |
nuclear_proximity_risk |
M6.5+ events within 50km of any nuclear plant |
decade_pattern_analysis |
Event counts and deaths grouped by decade |
fault_zone_lethality |
Total deaths attributed to each fault zone |
the_hamaoka_question |
Hamaoka nuclear plant specific risk analysis |
region_vulnerability_score |
Composite risk score per prefecture |
graph_summary |
Node and relationship counts across the full schema |
Text2Cypher
Natural language → Cypher generation. Examples:
-
"Which prefectures on the Nankai Trough also have nuclear plants?"
-
"What M7+ earthquakes struck Miyagi in the 2000s?"
-
"Which fault zone has caused the most deaths?"
-
"Show me every earthquake that triggered a tsunami and hit an active nuclear plant"
Similarity Search
Given a simulated earthquake, the agent finds historical analogs by magnitude, depth, and location:
MATCH (e:Earthquake)
WHERE abs(e.lat - $lat) < 3 AND abs(e.lon - $lon) < 3
AND abs(e.magnitude - $mag) < 1.5
OPTIONAL MATCH (e)-[:ORIGINATED_ON]->(fz:FaultZone)
OPTIONAL MATCH (e)-[:TRIGGERED]->(t:Tsunami)
RETURN e.id, e.magnitude, e.year, e.place, fz.name, t.max_height_m
ORDER BY abs(e.magnitude - $mag) + abs(e.lat - $lat) + abs(e.lon - $lon)
LIMIT 5
Vector semantic search is also available over node embeddings using Voyage AI voyage-3 (1024-dim) across all five node types: Earthquake, FaultZone, NuclearFacility, Prefecture, and Tsunami.
ConspiracyGraph Agent
What it does
ConspiracyGraph Agent is a narrative and claim relationship agent for fact checked misinformation.
It is not a normal fact check bot that only answers “true” or “false”. Instead, it explains how a user supplied claim connects to known fact checked claims, broader narrative frames, topics, entities, publishers, and evidence.
This lets the agent answer questions like:
Is this claim a variation of an older claim?
What narrative frame does it use?
Which entities connect it to other claims?
Which fact checks and publishers are connected to it?
Dataset and why a graph fits
The dataset is derived from the Google Data Commons Fact Check dataset, which aggregates structured fact check data from fact checking organizations worldwide.
Dataset source: Google Data Commons Fact Check dataset
https://datacommons.org
Dataset description:
https://datacommons.org/factcheck/download
The raw data is based on the schema.org/ClaimReview standard and contains structured fields such as:
claimReviewed
reviewRating
ratingExplanation
fact check URL
publisher
publication date
The data comes from publishers such as PolitiFact, FactCheck.org, BBC Reality Check, Washington Post, Logically Facts, FACTLY, Vera Files, Youturn, and The Healthy Indian Project.
The important point is that this is not a random conspiracy dataset. It is real world fact checked data. Each claim is linked to its source, verdict, publisher, and explanation.
A table can store fact checks.
A graph can explain how they are connected.
Data pipeline
I used a two step pipeline to turn the raw fact check data into a context rich graph.
First, the original fact check claims were cleaned, normalized, and scored. This included normalizing claim text, publishers, verdicts, dates, and stable IDs, then filtering for conspiracy related signals such as false flags, hidden elites, microchips, vaccine danger, climate hoax, election fraud, and global governance narratives.
Second, the selected candidate claims were embedded and semantically clustered. Each cluster was then enriched with structured information such as a canonical claim, specific topics, broad topics, narrative frames, entities, and a short explanation of why the claim is relevant to conspiracy narratives.
Graph schema
Node labels
| Label | Count | Meaning |
|---|---|---|
| ClaimVariant | 242 | Exact checked claim wording |
| Claim | 218 | Canonical claim cluster |
| FactCheck | 239 | Fact check article |
| Publisher | 28 | Fact checking organization |
| TheoryTopic | 205 | Specific topic labels |
| BroadTopic | 78 | Higher level topics |
| NarrativeFrame | 43 | Recurring narrative patterns |
| Entity | 229 | People, organizations, places, concepts, events |
Relationship types
| Relationship | Count | Meaning |
|---|---|---|
EXPRESSES |
268 | ClaimVariant to canonical Claim |
CHECKS |
242 | FactCheck to checked ClaimVariant |
PUBLISHED_BY |
239 | FactCheck to Publisher |
BELONGS_TO |
519 | Claim to TheoryTopic |
HAS_BROAD_TOPIC |
474 | Claim to BroadTopic |
USES_FRAME |
399 | Claim to NarrativeFrame |
MENTIONS |
295 | Claim to Entity |
Overall graph size:
1,282 nodes
2,436 relationships
Why this is more than semantic search
A semantic search system can find text that sounds similar.
ConspiracyGraph Agent goes further: it explains why claims are related.
For example, a claim like:
“COVID vaccines contain microchips”
can connect to:
Secret Technology
Population Control
Health and Vaccines
Bill Gates
Pfizer
COVID-19 vaccine
fact checks from multiple publishers
Agent tools
The Aura Agent uses similarity search plus Cypher templates.
1. Similar Claim Finder
Type: Similarity Search
Searches over ClaimVariant.embedding using the vector index claim_variant_embedding_idx.
Purpose:
User claim → closest known ClaimVariant
2. Claim Narrative Context
Type: Cypher Template
Input: variant_id
Returns the matched variant, canonical claim, frames, topics, entities, same-cluster variants, fact checks, publishers, verdicts, and URLs.
3. Related Narrative Claims
Type: Cypher Template
Input: variant_id
Finds broader narrative relatives through shared NarrativeFrame, BroadTopic, and Entity nodes.
4. Fact Check Evidence
Type: Cypher Template
Input: variant_id
Returns publisher, verdict, original verdict, explanation, date, fact check URL, and publisher URL.
5. Frame Explorer
Type: Cypher Template
Input: frame_name
Explores frames such as:
Secret Technology
Poisoned Medicine
Fake Event
Hidden Agenda
Election Theft
Population Control
Cover Up
Manipulated Science
6. Entity Bridge Explorer
Type: Cypher Template
Input: entity_name
Shows how entities such as Bill Gates, NASA, CDC, FDA, Pfizer, United Nations, World Economic Forum, or Donald Trump connect different claims and narratives.
7. Graph Statistics Fallback
Type: Text2Cypher
Used only for open ended statistics, counts, rankings, or aggregations not covered by the other tools.
Agent in action
Example 1: COVID vaccine danger claims
User question:
I keep seeing claims that COVID vaccines are dangerous. What patterns do you see?
The agent matched this to a claim variant about COVID vaccines being released as a depopulation measure.
It then connected the matched claim to:
Canonical claim:
The COVID-19 vaccine is part of a depopulation agenda.
Narrative frames:
Population Control
Poisoned Medicine
Topics:
depopulation
vaccine side effects
vaccine safety
Health and Medicine
Related claims:
COVID vaccines cause infertility
COVID vaccines are part of a depopulation agenda
COVID vaccines contain microchips for tracking and control
COVID vaccines alter human DNA
Fact check evidence:
PolitiFact
Reuters Fact Check
Lead Stories
The important part is that the agent does not only return one debunk. It shows a broader vaccine harm narrative and the evidence connected to it.
Example 2: Climate change and manipulated science
User question:
Someone claimed that climate change is a hoax and that NASA is misleading the public. What does the graph show?
The agent matched this to:
“NASA admits that man-made climate change is a hoax!”
It connected the claim to:
Narrative frame:
Manipulated Science
Broad topic:
Climate and Environment
Entity:
NASA
Fact check evidence:
Vishvas News
Verdict: False
Fact check URL
This shows how a specific claim connects to a broader pattern of institutional distrust and manipulated science narratives.
Why this agent is useful
Fact checks are usually published as isolated articles. That helps verify one claim, but it does not explain how misinformation narratives repeat and evolve.
ConspiracyGraph Agent turns isolated fact checks into a connected claim graph.
It helps answer:
- Have we seen this claim before?
- Is this a variation of a known fact checked claim?
- What broader narrative does it use?
- Which entities appear across related claims?
- Which publishers checked it?
- What evidence is available?
This can support e.g. journalists, researchers and fact checkers.
Final takeaway
ConspiracyGraph Agent is a context building agent for misinformation narratives.
It does not just answer:
- Is this claim false?
It answers:
- How does this claim fit into a broader narrative?
- Which known fact checked claims is it similar to?
- Which frames, topics, and entities connect it to other claims?
- Which fact checks, verdicts, and publishers are linked to the claim?
That is why this works well as a graph powered Aura Agent
Hello. Thank you for hosting such a great tournament.
I have a question regarding the credits you gave me. How can I check the credits on Aura?
2026년 4월 28일 (화) 오전 4:22, Neo4j Community Manager <notifications@neo4jcommunity.discoursemail.com>님이 작성:
Hi and welcome to the community @epiphanyan. If you successfully redeemed them, they are there. I did learn that they do not currently show up on the dashboard for the Aura Free accounts, but they are there to use. DM me if you have any further questions.
Added to the ticker banner 
If you submitted or are planning to submit your project, feel free to tag yourself on the LinkedIn post. If you already submitted, your projects are mentioned, but each of you have the opportunity to tag yourself.
Here is the link:
- @mabu.mate — Apple HealthGraph Agent
- @venkatasaiprasadp — DepGraph Agent
- @dhiraj.patra — RegulatoryRisk GraphAgent
- @shantanunitw01 — CineGraph AI
- @jevlachov — Korca Triage Agent
- @deanfoulds — Japan Seismic Risk Intelligence Graph
- @jonas.koenner — ConspiracyGraph Agent
-
Agent Name : Detect Cyber Attack
-
Github Link: GitHub - prashant7090/detect-cyber-attack: Detech Cyber Attack - Graph database - Neo4j · GitHub
-
What it does :
- Find suspicious IPs, repeated malicious destinations, or abnormal traffic patterns.
- Detect suspicious clusters of source IPs targeting the same destination
- Visualize relationships between events and IPs
- Identify repeated
AttackType - Use graph traversals to connect IPs, events, protocols, and attack categories.
-
Dataset and why a graph fits
- Cybersecurity Threat Detection Dataset | Kaggle
- The dataset is naturally relational: sources, destinations, protocols, and attack labels are all connected.
- Neo4j lets you query those connections directly instead of flattening them in tabular form.
- This supports use cases like - find all source IPs that have attacked the same destination” or “group events by attack type and protocol.
-
Screenshot of your agent in the Aura console
Hi, I had completed the course and submitted the form on 27 April. I haven't received the free credit, so I submitted another form just now. Can you help me to check? Thank you
Thank you @tiffanyseah94. For some reason your previous form was not received. However, we did get your most recent submission, and your credits should be processed by EOD tomorrow. Thank you for your patience and we can't wait to see what you will build!
FinSight
FinSight is a Neo4j-powered fraud investigation agent for finding suspicious account networks in financial transaction data. It turns raw IEEE-CIS fraud records into an explorable graph so an investigator can see not only which accounts are risky, but also why they look connected.
Agent Name
FinSight
Git: https://github.com/mahanteshimath/FinSight
What It Does
FinSight helps fraud analysts investigate connected risk across accounts, devices, and merchants. It loads transaction and identity data into Neo4j Aura, then presents a live dashboard where users can:
-
inspect account, device, and merchant relationship counts;
-
filter the graph to fraud-connected activity;
-
click any node to expand its 1-hop or 2-hop neighborhood;
-
trace shared devices and merchant/product links behind suspicious accounts;
-
view fraud samples with the supporting graph context instead of a flat score;
-
switch between light and dark themes for a cleaner investigation workspace.
The goal is to make fraud investigation feel like following evidence, not scanning isolated rows.
Dataset and Why a Graph Fits
Dataset: IEEE-CIS Fraud Detection Dataset, using train_transaction.csv and train_identity.csv.
FinSight loads the first 50,000 transaction rows by default and merges transaction and identity records on TransactionID.
The graph model focuses on the entities that make fraud networks discoverable:
-
Accountnodes from card/account identifiers -
Merchantnodes from product or merchant-like transaction categories -
Devicenodes from device identity fields -
(:Account)-[:AT_MERCHANT]->(:Merchant) -
(:Account)-[:USES_DEVICE]->(:Device)
A graph fits because fraud is rarely isolated. A single account can look normal on its own, while its neighborhood reveals that it shares a device with known fraud accounts or repeatedly appears near the same merchant/product patterns. Neo4j makes those multi-hop relationships easy to ask and easy to explain:
MATCH (fraud:Account {risk_score: 1})-[:USES_DEVICE]->(d:Device)<-[:USES_DEVICE]-(neighbor:Account)
RETURN fraud.id, d.id, neighbor.id, neighbor.risk_score
That is the core idea behind FinSight: relationship structure becomes evidence.
Query history from Neo4j Aura:
Try this flow:
-
Open the deployed FinSight dashboard.
-
Go to
/graph. -
Turn on Fraud-connected only.
-
Click a risky account node.
-
Switch between 1-hop and 2-hop neighborhoods.
-
Show the shared device or merchant path that explains the suspicious connection.
Link
- Live Agent: FinSight on Vercel
Why FinSight Stands Out
The Graph Matters
FinSight does not use Neo4j as a visual spreadsheet. The relationships drive the insight. Shared devices and repeated merchant/product connections let the agent surface suspicious neighborhoods that would be hard to notice from individual transaction rows.
Built for a Real Investigator
The dashboard supports the actions an analyst would actually take: filter to risky activity, adjust graph density, expand neighborhoods, reset focus, inspect the evidence path interactively, and switch themes for comfortable analysis.
It Explains the Why
Instead of returning only "fraud" or "not fraud," FinSight shows the connected context: which account is risky, which device or merchant connects it to other activity, and how far the relationship is from the focus node.
Presentation Ready
The project includes a Neo4j Aura loader, verification script, live query evidence, dashboard demo, Next.js dashboard, and Vercel deployment.
Live Neo4j Aura Query Evidence
All summarized investigation queries were successfully executed in Neo4j Aura on the IEEE-CIS Fraud Detection graph. The query history demo above shows the live execution path, and the results below summarize what the graph revealed.
Graph Structure Confirmed Live
| Entity | Count |
|---|---|
| Account nodes | 5,446 |
| Device nodes | 590 |
| Merchant nodes | 5 |
AT_MERCHANT relationships |
7,439 |
USES_DEVICE relationships |
5,352 |
Properties: Accounts have id, risk_score, and email_domain. Devices have id and type. Merchants have id.
Query Results Summary
Query 1 - Node Counts by Label
-
Account: 5,446
-
Device: 590
-
Merchant: 5
Query 2 - Relationship Types
-
AT_MERCHANT: 7,439 -
USES_DEVICE: 5,352
Query 3 - Property Inventory
-
All 3 Account properties,
id,risk_score, andemail_domain, exist on every Account node. -
Verified in the Neo4j Aura query console.
Query 4 - Risk Score Distribution
-
Minimum risk score: 0
-
Maximum risk score: 1
-
Average risk score: ~0.0141
-
Interpretation: the graph is highly skewed toward low-risk accounts, with a small but important group flagged at maximum risk.
Query 5 - High-Risk Accounts (risk_score = 1)
-
Found high-risk accounts such as
17325(hotmail.com),1775(gmail.com),17739(anonymous.com), and7794(hotmail.com). -
Suspicious or disposable-looking email domains become more meaningful when combined with graph structure.
Query 6 - Device Sharing: Most Connected Devices
| Device | Type | Accounts Sharing It |
|---|---|---|
| Windows | desktop | 1,546 |
| iOS Device | mobile | 860 |
| MacOS | desktop | 640 |
| Trident/7.0 | desktop / IE | 505 |
| rv:11.0 | desktop | 142 |
Query 7 - Merchant Risk Exposure
| Merchant | Accounts | Avg Risk |
|---|---|---|
| W | 3,655 | 0.009 |
| H | 1,751 | 0.011 |
| R | 1,058 | 0.016 |
| S | 489 | 0.010 |
| C | 486 | 0.045 |
Merchant C has the highest average risk score among all merchants in this graph.
Query 8 - Fraud Ring Detection
Multiple high-risk accounts, including 3154, 10876, 7794, 8528, 5812, 11920, and 10493, all share Device ID 18306 (Windows, desktop). This is a classic fraud-ring pattern: many fraudulent accounts operating from the same device.
Key Insight
Device 18306 is a fraud-ring hub because it connects many accounts with risk_score = 1. Merchant C has the highest average merchant risk score at approximately 0.045. Together, these are the most actionable fraud signals found in the current graph.
Technical Quick Start
FinSight loads IEEE-CIS fraud data into Neo4j Aura and visualizes it with a Next.js dashboard.
Contributor
Mahantesh Hiremath
Thank you very much.
Hi I have completed the course and would like to claim the $100 in aura credits. I have submitted the form as requested. Thanks Michael.
Hi, I have completed the course, received the mail for the aura credits, redeemed them, but still they are not available, what can be the problem?
Hi Nada.- if you are using an Aura Free account and you successfully redeemed them - they are there but do not show up on the Dash Board.. I have shared it with product, but you will be able to use the credits when you try. Let us know if for some reason you cannot.
